[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

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

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
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
       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?

       - 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

             (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 and derived from
                   the actual public key.


                   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
                               form of the key
                               digest, for
                               example the
                               first 8 bytes of
                               the key
                               digest instead
                               of the full 32

                         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.
                         "chaffing and winnowing"
                         even relies on not sending
                         any KeyID bits, on

                               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
                         KeyDigest bits consist of 2
                         to 32 of the
                         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

                         best, c

                               - Jeff T
                               From: Junxiao
                               <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
                               Date: Wednesday,
                               May 27, 2015 at
                               To: Jeff
                               <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
                               "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:
                               Describe the
                               HMAC algorithm
                               Dear folks
                               Details about
                               HMAC algorithm,
                               or any other
                               NOT appear in
                               NDN Packet
                               Instead, the
                               should be
                               referred to RFC.
                               Those details
                               are duplication
                               of RFC, and they
                               would make the
                               They also
                               increase the
                               probability of
                               because the
                               implementer is
                               whether it's
                               exactly same as
                               what she/he has
                               in the library,
                               would have to
                               implement it
                               "don't have HMAC
                               in their crypto
                               library" is not
                               a valid argument
                               it's easier to
                               find an
                               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>>
                                   The proposed
                               spec (below)
                               repeats the
                               details of the
                               from RFC 2104.
                               But should the
                               details be
                               removed and
                               just refer to
                               RFC 2104?
                               for keeping the
                               details are that
                               it provides
                               for the
                               discussion of
                                   creating the
                               KeyDIgest and
                               also because
                               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
                               RFC if needed,
                               and that we
                                   don't repeat
                               the details of
                               other algorithms
                               like SHA-256.
                               Any opinions on
                               removing the
                               - Jeff T

                         Ndn-interest mailing list
                         Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>

-------------- 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