[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
understanding...
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
followed.
...
The quality of the protection provided by the MAC depends on the
randomness
This should be entropy.
of
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]
