general defensive crypto coding principles

On 2/8/06, Jack Lloyd <lloydrandombit.net> wrote:
> An obvious example occurs when using a
> deterministic authentication scheme like HMAC - an
attacker can with high
> probability detect duplicate plaintexts by looking for
identical tags.

I think though that the solution is fairly simple; prepend a
block-length random IV to the message and to the output of
HMAC.

In fact, I've wondered if doing this on all hashes might be
a good
defensive programming idea.  It seems to defend against
attacks of the
sort which /etc/passwd was subject (dictionary cracking) in
much the
same way that salt did*, and against guessing the plaintext
for short
plaintexts even when the language is unknown.

[*]  Salts of course defended against hardware
implementations by
perturbing the S-tables instead of altering the input.
--
"Cryptography is nothing more than a mathematical
framework for discussing
various paranoid delusions." -- Don Alvarez
http://www.li
ghtconsulting.com/~travis/ -><-
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A
94C2 641B

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Travis H. wrote:
> On 2/8/06, Jack Lloyd <lloydrandombit.net> wrote:
>> An obvious example occurs when using a
>> deterministic authentication scheme like HMAC - an
attacker can with high
>> probability detect duplicate plaintexts by looking
for identical tags.
> 
> I think though that the solution is fairly simple;
prepend a
> block-length random IV to the message and to the output
of HMAC.
> 
> In fact, I've wondered if doing this on all hashes
might be a good
> defensive programming idea.  It seems to defend against
attacks of the
> sort which /etc/passwd was subject (dictionary
cracking) in much the
> same way that salt did*, and against guessing the
plaintext for short
> plaintexts even when the language is unknown.

It also defends against the MD5 crack, and is one of the
recommended
IETF solutions to hash problems.

-- 
http://www.links.org/

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

At 5:40 PM +0000 2/12/06, Ben Laurie wrote:
>It also defends against the MD5 crack, and is one of the
recommended
>IETF solutions to hash problems.

s/recommended/proposed/

The IETF has not recommended any "solutions to hash
problems". The 
sense of the room at the Hash BOF and the SAAG discussion at
the 
Paris IETF meeting was that the IETF should *not* propose
solutions 
to the problem. That is why the BOF did not turn into a
Working Group 
and why there has been little discussion of the proposed
solutions in 
the relevant IETF working groups.

--Paul Hoffman, Director
--VPN Consortium

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com