[to and CC trimmed]
----- Original Message ----- From: "' =JeffH '" <[EMAIL PROTECTED]> To: ""Hal Finney"" <[EMAIL PROTECTED]>; "Eric Rescorla" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Joseph Ashwood" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <cryptography@metzdowd.com>
Sent: Thursday, February 07, 2008 2:17 PM
Subject: Re: questions on RFC2631 and DH key agreement

I think I already know the answer to this question, but I just want to test my

How wise (in a real-world sense) is it, in a protocol specification, to
specify that one simply obtain an ostensibly random value, and then use that value directly as the signature key in, say, an HMAC-based signature, without any further stipulated checking and/or massaging of the value before such use?

With any authentication the biggest consideration is to examine what the intention is. Using a single-use one time key for a symmetric MAC works for local authenticity, but not for remote authenticity. That is to say that the local process knows that it didn't generate the MAC, and the MAC is shared with only one other, so the authenticity is known, but any external source can only say that an entity knowing the key generated it. This may or may not be the intended condition, in that auditing this is very, very difficult.

E.g., here's such a specfication excerpt and is absolutely everything said in
the spec wrt obtaining said signature keys:

 When generating MAC keys, the recommendations in [RFC1750] SHOULD be
The quality of the protection provided by the MAC depends on the randomness

This should be entropy.

 the shared MAC key, so it is important that an unguessable value be used.

How (un)wise is this, in a real-world sense?

It all depends on the intended meaning. If this is intended to authenticate to a third party, it fails completely. If it is specifically intended NOT to authenticate to a third party it may be exactly what is needed. Joe
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to