[Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256?
christian.tschudin at unibas.ch
christian.tschudin at unibas.ch
Tue Jun 2 00:38:28 PDT 2015
On Mon, 1 Jun 2015, 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> 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
>
>
>
>
More information about the Ndn-interest
mailing list