[Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?

Marc.Mosko at parc.com Marc.Mosko at parc.com
Mon Jun 1 14:32:17 PDT 2015


I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another.  If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched.

I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest.

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.

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/20150601/a3532ac7/attachment.html>


More information about the Ndn-interest mailing list