picking a hash function to be encrypted

Victor Duchovni Victor.Duchovni at MorganStanley.com
Sun May 14 19:32:39 EDT 2006


On Sun, May 14, 2006 at 03:04:41AM -0500, Travis H. wrote:

> Suppose I want a function to provide integrity and authentication, and
> that is to be combined with a stream cipher (as is the plaintext).  I
> believe that authentication is free once I have integrity given the
> fact that the hash value is superencrypted using the stream cipher,
> whose key is shared by only the sender and recipient.  I believe what
> I'm looking for is a strongly universal hash.  I don't need much;
> everything I've seen is simultaneously too much and too little, often
> calling upon a block cipher, which seems redundant.
> 
> What I was thinking of doing was using Poly1305, and using the stream
> cipher instead of AES.  I think in this case that I can leave the MAC
> exposed, since it's a MAC and not a hash.  Is there an analogous, hash
> function that does not use encryption internally?
> 

Security is fragile. Deviating from well understood primitives may be
good research, but is not good engineering. Especially fragile are:

- Non-mainstream ciphers (often broken once someone good bothers to try)
- Stream ciphers (additive)
- RC4 (poor key schedule)
- RSA (multiplicative)

The first is to be avoided entirely, the second and third should be
used only under duress, when block ciphers are a very poor fit for the
application. RSA needs to be used only in very specific ways (PKCS 2.1,
for example) that avoid the common pitfalls.

TLS (available via OpenSSL) provides integrity and authentication, any
reason to re-invent the wheel? It took multiple iterations of design
improvements to get TLS right, even though it was designed by experts.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

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



More information about the cryptography mailing list