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

Mon Jun 1 12:10:58 PDT 2015

Hi Jeff,

maybe I make a too far-fetching intepretation of your suggestion, but 
this would be a hefty price to pay: Forcing all principles to name their 
keys, globally, just to avoid the introduction of "truncated key digest" 
in the spec?

Concept-wise there is no key to locate and fetch (via NDN) here, just an 
optional speedup inside the validator's memory.

best, christian

On Mon, 1 Jun 2015, Thompson, Jeff 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"
> <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 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>
>>> <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>
>>>>> Date: Wednesday, May 27, 2015 at 5:10
>>>>> To: Jeff Thompson <jefft0 at remap.ucla.edu>
>>>>> Cc: "ndn-interest at lists.cs.ucla.edu" <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> 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
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>
>