[Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?
Thompson, Jeff
jefft0 at remap.ucla.edu
Tue Jun 2 09:08:45 PDT 2015
Hi Christian,
If I understand, you suggest that the recipient should try to validate the signature using all available keys, and any key locator is just something which would narrow down the keys to try? More strongly, you're suggesting that we give up on the idea that a KeyLocator should uniquely identify the key needed to verify?
- Jeff T
On 2015/6/2, 0:38, "christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>" <christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>> wrote:
On Mon, 1 Jun 2015, Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> wrote:
...
To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one
would need to introduce a new TLV container “KeyIndex” or something like
that to accommodate negotiated key IDs in a key exchange protocol.
I agree.
If we move away from using a hash or other intrinsic key properties, as
Gene suggests, the simplest process would be random bits instead of
requiring a negotiation of key IDs and making assumptions on persistent
state.
Collisions would be normal (they also happen with negotiated keyIDs,
over long enough time), wherefore one could call it "KeyBin" instead of
"KeyIndex": the signer anounces the bin in which the signing key can be
found.
best, christian
To accomodate truncated KeyDigest, one could use a new container. However,
if it is a truncated SHA256, then I think it would be obvious that it is
only the “length” bytes of the SHA256, not the full 32-bytes. I could see
allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of
specificity.
Marc
On Jun 1, 2015, at 7:42 PM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Christian and Marc,
I think we agree that we'll spell out how to get the key digest
from the
Key, but not spell out the HMAC algorithm itself (or how Key is
padded to
make the internally-used KeyValue).
If the applications want to use an integer identifier for the
Key, then
the KeyLocator would need to be a Name with the integer as a
name
component, right?
Also, if the "truncated key digest" (maybe as short as a byte)
is used as
an identifier, I wonder whether this should be in a Name too.
This way,
we don't mess with the semantics of KeyDigest which usually
means the full
digest. What do you think?
Thanks,
- Jeff T
On 2015/6/1, 9:48, "christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>"
<christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>> wrote:
I understood Jeff wanting to make the spec as
self-contained as
possible, but I doubt that a reference to an
HMAC-internal variable is
helping.
(It translate into "Dear NDN implementor, to
implement this two-line
feature you need to read the following RFC and
locate that Keyval
variable in your favorit shrinked-wrapped library."
As a probe: the
Python hashlib API page does not reference it).
So better write at least that part out?
Regarding how to choose the KeyId (hash, ISAKMP SPI
etc): I see, so it
make sense to point out the many possibilities to
pick your way. At
least an advantage of the currently discussed
hashing approach would
be to not add another document to read 8-)
best, c
On Mon, 1 Jun 2015, Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> wrote:
The proposed spec already defines
KeyValue as the right-padded (for
short keys) or sha256 (for long keys) of
the Key. I would define the
KeyDigest as the SHA256(KeyValue) and
not repeat the same algorithm used
to compute KeyValue.
With regard to repeating the definition
of HMAC, I would not do that
but simply say that the Œtext¹ input to
HMAC is {Name, MetaInfo,
Content, SignatureInfo} TLVs.
For symmetric key systems, like HMAC, I
think it is also acceptable to
use an agreed upon integer identifier
for the shared secret, as
determined by a key exchange protocol
(e.g. an ISAKMP SPI). I don¹t
think that symmetric key KeyDigests need
to be derived from the key.
That¹s different than public key
systems, where the the KeyDigest is
used like the Subject Key Identifier
(RFC 5280 4.2.1.2) and derived from
the actual public key.
Marc
On Jun 1, 2015, at 1:45 PM,
<christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>>
<christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>> wrote:
On Wed, 27 May 2015,
Thompson, Jeff wrote:
Hello Christian,
Two questions:
1. Can you
repeat your
suggestion that
the spec allow a
truncated
form of the key
digest, for
example the
first 8 bytes of
the key
digest instead
of the full 32
bytes?
Hi Jeff,
This is a trick that Marc
Mosko used when we presented
the 1+0
encoding at the January
ICNRG interim meeting: Just
reduce then number
of KeyID-Bits (2 Bytes, in
our case), if need be.
The observation is that the
key digest is for
convenience, not
security reasons: If you
have many parties for which
you have to
maintain different symmetric
keys, it is nice to quickly
identify which
key to use for validating
the signature. But
theoretically, you could
just try out all symmetric
keys you have for some peer.
Rivest's
"chaffing and winnowing"
even relies on not sending
any KeyID bits, on
purpose.
2. If you want
this suggestion
on the spec,
what is the best
way to
describe the
computation of
the key digest
if we don't
describe the
HMAC algorithm
in the spec?
First, it could be made
optional. But then I think
it would be good to
write down how the digest is
computed, as you suggest
(because RFC 2104
does not cover it, right?)
Adapted from previous text
of yours:
"The Key must not be
included in the signature
but optionally a full
or partial KeyDigest can be
put in the KeyLocator block
of the
SignatureInfo field. If the
byte length of Key is less
than or equal to
the SHA256 block length (64
bytes) then the full length
KeyDigest is
SHA256(Key). But if the byte
length of Key is greater
than 64 bytes,
the KeyValue is already
SHA256(Key) with zeros
appended, so in this
case the full length
KeyDigest is
SHA256(SHA256(Key)). The
optional
KeyDigest bits consist of 2
to 32 of the
most-significant
(=left-most)
bytes of the full length
KeyDigest. For the
convenience of the
validator and if packet size
permits, it is recommended
to include the
full 32 bytes."
Would that be precise
enough?
best, c
Thanks,
- Jeff T
From: Junxiao
Shi
<shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wednesday,
May 27, 2015 at
5:10
To: Jeff
Thompson
<jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc:
"ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>"
<Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>>
Subject: Re:
[Ndn-interest]
Describe the
HMAC algorithm
in
SignatureHmacWithSha256?
Dear folks
Details about
HMAC algorithm,
or any other
crypto
algorithm,
SHOULD
NOT appear in
NDN Packet
Format
spec.
Instead, the
implementer
should be
referred to RFC.
Those details
are duplication
of RFC, and they
would make the
spec
unnecessary
long.
They also
increase the
probability of
incorrect
implementations
because the
implementer is
unsure
whether it's
exactly same as
what she/he has
in the library,
and
would have to
implement it
again.
"don't have HMAC
in their crypto
library" is not
a valid argument
-
it's easier to
find an
RFC-compliant
library or
snippet for most
languages than
to implement
according to the
(duplicate of
RFC in) spec.
Yours, Junxiao
On Mon, May 18,
2015 at 4:00 PM,
Thompson, Jeff
<jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
wrote:
The proposed
SignatureHmacWithSha256
spec (below)
repeats the
details of the
HMAC
algorithm
from RFC 2104.
But should the
details be
removed and
just refer to
RFC 2104?
Arguments
for keeping the
details are that
it provides
details
for the
discussion of
creating the
KeyDIgest and
also because
some
applications
don't
have HMAC in
their crypto
library and
need to
implement it
directly. An
argument against
keeping the
details is that
the info is
in RFC 2104 so
an application
writer can read
the
RFC if needed,
and that we
don't repeat
the details of
other algorithms
like SHA-256.
Any opinions on
removing the
algorithm
details?
- Jeff T
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150602/dd86e6e3/attachment.html>
More information about the Ndn-interest
mailing list