draft paper: "Deploying a New Hash Algorithm"

[Alex Alten]

Steve,

At 05:34 PM 7/29/2005 -0400, Steven M. Bellovin wrote:
>In message <4.3.2.7.1.20050727003848.03f64d50 at mail.alten.org>, Alex Alten 
>write
>s:
> >At 08:12 AM 7/25/2005 -0400, Steven M. Bellovin wrote:
> >>In message <4.3.2.7.1.20050725003455.0470c6f8 at mail.alten.org>, Alex Alten
> >>write
> >>s:
> >> >Steve,
> >> >
> >> >This also seems to be in conjunction with the potential switch over from
> >> >RSA et al. to
> >> >ECC for PKI, etc.
> >> >
> >>
> >>Yes, Eric and I have been talking about that, and we'll add some
> >>discussion of that to the next version of the paper.
> >
> >Variable output is really needed too, say 16, 32, 64, 128, 256 and 512 bits.
> >And on the wishful side, the ability to optimize compression across
> >multiple CPUs.
> >
>
>That's completely orthogoal to what the paper is about.  We're talking
>about how to convert to *any* new hash algorithm; we're not concerned
>with which is chosen.  (I confess, though, that hash outputs of less
>than 128 bits don't strike me as cryptographically useful except for
>HMAC and the like.)

Sorry for going off on a tangent.

Actually 32 (or even 16) bits is really useful for retrofitting old 
insecure protocols where you
don't want to alter the header size, you only need access control, and the 
packets only exist
for less than 100 msecs.

- Alex

--

- Alex Alten


[Moderator's note: I have to strongly disagree. 16 bits is rarely, if
ever, of any use in authentication in a modern system. Even if you
think something can't live long enough to be spoofed, it usually can,
and as it turns out, attackers are often cleverer than protocol
designers. Crypto is too brittle to play such games with it. --Perry]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com