questions on RFC2631 and DH key agreement

[Joseph Ashwood]

[to and CC trimmed]
----- Original Message ----- 
From: "' =JeffH '" <Jeff.Hodges at KingsMountain.com>
To: ""Hal Finney"" <hal at finney.org>; "Eric Rescorla" 
<ekr at networkresonance.com>; <pgut001 at cs.auckland.ac.nz>; "Joseph Ashwood" 
<ashwood at msn.com>
Cc: <Jeff.Hodges at KingsMountain.com>; <cryptography at 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 majordomo at metzdowd.com