headers
Paul Hoffman | 5 Dec 2005 23:53

Re: [saag] Structure of documents discussing protocols and hashes

At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote:
>My view is that there is no need to RUSH into upgrading SHA-1 in
>IKEv1 or v2. The only place where the recent attacks have a direct
>relevance is in public key certificates. Other uses of hashes in IKE
>(which include PRF, MAC, ephemeral signatures, and the randomness
>extraction functionality referred to by David's mail) would have some
>benefit from a hash function upgrade but nothing truly urgent. None of
>these uses are based on collision resistance in some essential way.
>Of course, new attacks, in particular on the pseudo-random properties of
>secretly-keyed HMAC, could be found in the future (or maybe even in the
>present), but such attacks to be of real significance will not be merely
>collision attacks.

The series of "hash evaluation" documents should give as specific 
numbers as possible.

Here, you say "there is no need to RUSH" and "nothing truly urgent". 
Do we know of any collision-reduction attacks now that would cause 
any issues with IKE or IPsec? If not, why is there any need to amble, 
much less rush, towards new hash functions?

Given that our preferred encryption algorithms are 112 and 128 bits 
strong, exactly where should we worry  about using MD5 or SHA1 in 
IPsec (other than in the PKIX part)? Of course, if someone uses 
AES-192 or AES-256, they probably want to use SHA-256, but that's not 
relevant here.

>First, we do not know how fast
>attacks will improve and reach the point of being relevant even for uses
>such as in IKE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven M. Bellovin | 6 Dec 2005 00:19

Re: [saag] Structure of documents discussing protocols and hashes

In message <p06230988bfba71ec5d63 <at> [10.20.30.249]>, Paul Hoffman writes:

>
>Here, you say "there is no need to RUSH" and "nothing truly urgent". 
>Do we know of any collision-reduction attacks now that would cause 
>any issues with IKE or IPsec? If not, why is there any need to amble, 
>much less rush, towards new hash functions?
>

Per mine and ekr's paper, the problem is that we *can't* switch, even 
if a serious problem developed.  What's really necessary now is to add 
the extra signaling, so that we can switch hash functions if and when 
that becomes necessary.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Permalink | Reply | 0 comments |
headers
Paul Hoffman | 6 Dec 2005 01:05

Re: [saag] Structure of documents discussing protocols and hashes

At 6:19 PM -0500 12/5/05, Steven M. Bellovin wrote:
>In message <p06230988bfba71ec5d63 <at> [10.20.30.249]>, Paul Hoffman writes:
>
>>
>>Here, you say "there is no need to RUSH" and "nothing truly urgent".
>>Do we know of any collision-reduction attacks now that would cause
>>any issues with IKE or IPsec? If not, why is there any need to amble,
>>much less rush, towards new hash functions?
>>
>
>Per mine and ekr's paper, the problem is that we *can't* switch, even
>if a serious problem developed.  What's really necessary now is to add
>the extra signaling, so that we can switch hash functions if and when
>that becomes necessary.

That is important, but orthogonal to my question for Hugo.

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 0 comments |
headers
Hugo Krawczyk | 8 Dec 2005 20:04
Picon

Re: [saag] Structure of documents discussing protocols and hashes

See below

On Mon, 5 Dec 2005, Paul Hoffman wrote:

> At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote:
> >My view is that there is no need to RUSH into upgrading SHA-1 in
> >IKEv1 or v2. The only place where the recent attacks have a direct
> >relevance is in public key certificates. Other uses of hashes in IKE
> >(which include PRF, MAC, ephemeral signatures, and the randomness
> >extraction functionality referred to by David's mail) would have some
> >benefit from a hash function upgrade but nothing truly urgent. None of
> >these uses are based on collision resistance in some essential way.
> >Of course, new attacks, in particular on the pseudo-random properties of
> >secretly-keyed HMAC, could be found in the future (or maybe even in the
> >present), but such attacks to be of real significance will not be merely
> >collision attacks.
>
> The series of "hash evaluation" documents should give as specific
> numbers as possible.
>
> Here, you say "there is no need to RUSH" and "nothing truly urgent".
> Do we know of any collision-reduction attacks now that would cause
> any issues with IKE or IPsec? If not, why is there any need to amble,
> much less rush, towards new hash functions?

Even if the functions we use today are not yet broken in a practical
sense, what is broken is our confidence on these functions, and we have to
act on this "broken confidence".  The way to do it is NOT by trying to
measure (quantify) every day what is the latest best attack, but rather we
should take advantage of the fact that most applications are currently NOT
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Richardson | 8 Dec 2005 22:47
Picon

Re: [saag] Structure of documents discussing protocols and hashes


>>>>> "Hugo" == Hugo Krawczyk <hugo <at> ee.technion.ac.il> writes:
    Hugo> different than Belovin-Rescorla.  As Steve has recently put
    Hugo> it:

    smb> Per mine and ekr's paper, the problem is that we *can't* switch,
    smb> even if a serious problem developed.  What's really necessary now
    smb> is to add the extra signaling, so that we can switch hash
    smb> functions if and when that becomes necessary.

    Hugo> The counter-part of this switching problem is (paraphrasing
    Hugo> the above): "even when we'll be ready to switch we won't know
    Hugo> to WHAT to switch".  That is, do not expect that we will be in
    Hugo> a situation where our confidence will be fully (or even

  My feeling is: pick something. SHA-256 is fine as a test case for
testing the ability to switch.  It might not be the right answer in
2010.

  I also continue to question if PRF uses are really affected.

--

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Permalink | Reply | 0 comments |
headers
Paul Hoffman | 9 Dec 2005 00:02

Re: [saag] Structure of documents discussing protocols and hashes

At 3:02 PM -0500 12/8/05, Sam Hartman wrote:
>We'd like to have quantified results to guide our thinking.  We don't
>have such results; we have educated intuition about the strengths of
>functions we are using.

We have both. We now have quantified results that tell us that the 
two popular hash functions have much-weaker-than-expected 
collision-resistance. We have another related quantified result: the 
initial attacks on these functions were improved on in less than a 
year. We have educated intuition that these attacks will probably get 
better.

>I think it would be irresponsible to ignore
>this intuition just as I think it irresponsible to panic.

Fully agree. But I don't see how the intuition affects the structure 
of of documents discussing protocols and hashes.

- Our desire for agility in choosing all cryptographic functions to 
use is based on solid quantified understanding that sometimes a 
devastating attack is found. The reasons we need agility today are 
exactly the same as they were three years ago, before the current 
attacks were found; no intuition there.

- We have quantified results that our earlier intuition about 
particular hash functions was wrong. We know for a fact that we 
should not to re-use the same intuition: we know we should look for 
things that don't match what we did before.

Where did you want the intuition to come in here?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugo Krawczyk | 9 Dec 2005 00:31
Picon

Re: [saag] Structure of documents discussing protocols and hashes


On Thu, 8 Dec 2005, Stephen Kent wrote:

> Hugo,
>
> I think it would be good to explore randomized hashing in the near
> term (said the non-cryptographer).At a minimum it might be good to
> develop RH-based integrity options for our various protocols, and see
> what the performance and engineering implications are.Would you
> envision using an hash algorithm like SHA-256 with randomization as a
> pre-processing step?

Exactly!  And not only with SHA-256, but with any other existing or future
hash function. I envision randomized hashing as a way to FREE digital
signatures from their dependency on collision resistance (much like HMAC
did for MAC functions)

> That might be an especially attractive approach
> for an interim hash function solution, given that NIST is likely to
> suggest a near term transition to SHA-256.
>

As said, I do not see this just as an interim approach, but rather
as a durable SAFETY NET for one of our most precious cryptographic
tools: digital signatures.

Now, while this approach does not require to change hash functions or to
build dedicated hash functions, it does require a change of data encoding
in digital signatures. This is not a trivial change but one we can afford
(and well worth the insurance it buys us). Moreover, if we are going to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 16 Dec 2005 23:59

Fwd: Comments requested on NIST Draft RNG Publication

 > Date: Fri, 16 Dec 2005 08:47:45 -0500
 > From: Elaine Barker <elaine.barker <at> nist.gov>
 > Subject: Comments requested on NIST Draft RNG Publication
 >
 > A draft NIST Special Publication (Draft SP 800-90, Recommendation for
 > Random Number Generation Using Deterministic Random Bit Generators) is
 > available for public comment at
 > http://csrc.nist.gov/publications/drafts.html.  Comments should be
 > submitted to ebarker <at> nist.gov by Wednesday, February 1, 2006. Please
 > place "Comments on SP 800-90" in the subject line.
 >
 > Elaine Barker
 > National Institute of Standards and Technology
 > 100 Bureau Drive, Stop 8930
 > Gaithersburg, MD 20899-8930
 > 301-975-2911
Permalink | Reply | 0 comments |

Gmane