The Pure Crypto Project's Hash Function

Eric Murray ericm at lne.com
Sat May 3 17:18:08 EDT 2003


On Sat, May 03, 2003 at 12:46:55PM -0400, Adam Shostack wrote:
> On Sat, May 03, 2003 at 05:28:24PM +0200, Ralf Senderek wrote:
> | On Sat, 3 May 2003, Rich Salz wrote:
> | > Isn't it better to have clean implementations of known algorithms that
> | > have been widely understood and studied by the cryptographic community?
> | 
> | > Smallest lines of code doesn't imply "most secure."
> | > 	/r$
> | 
> | The goal is of course : "most secure" AND "most clear" AND "smallest code"
> 
> Do you want good, fast, and cheap, too?
> 
> I'd be much more comfortable with a standard hash function than one
> designed in the hopes of reducing code size, for any project except
> one where gate count matters.

This idea doesn't actually reduce code size.  Look at
any software implementation of modexp or the libraries plus
device drivers for any hardware modexp.  
The code for a simple implementation of SHA1 is trivial
in comparison to either of those.  But even the simplest
bignum modexp isn't a trivial amount of code.
This idea is only "small code size" if one waves his hands
over the details of the modexp implementation...

And of course doing a modexp for _each byte_ of the hash would
make this unbeleivably slow.

> Small code is only useful for ease of review, and bug resistance.
> However, code reuse also accomplishes those same goals.  There seems
> to be a lot of audit work done on openssl, use their sha
> implementation, or get NIST's.  You get a solid hash function, and the
> important benefits of small code.

SHA1 as a primitive can be used for other things
like making a symmetric encryption algorithm.  There have
even been some research papers published on the strength
of SHA-MDC.

Eric


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list