Hand Waving vs. Rigorous Analysis... (was Security Engineering vs. Crypto Academics...)

From: Patrick J. LoPresti (patl_at_users.sourceforge.net)
Date: 08/31/04 

Date: 31 Aug 2004 10:38:45 -0400

tytso@mit.edu (Theodore Y. Ts'o) writes:

> "Patrick J. LoPresti" <patl@users.sourceforge.net> writes:
> > If SHA-1 is strong, then truncation and XOR are (provably) equally
> > good. If SHA-1 has some unspecified weakness, then truncation and
> > XOR are equally suspect. Either way, the XOR is pointless.
> > Contortions like this make academics roll their eyes, not because
> > they have unwarranted faith in the crypto, but because you have
> > simply added complexity which makes analysis harder and does nothing
> > to improve security.
>
> Umm.... either this "contortion" (which takes 3 lines of C code!) is
> trivial, in which case it doesn't make the analysis any harder, or it
> isn't, in which case it might help. You can't have it both ways....

When talking about cryptography, "trivial" is not measured in lines of
code. Very small changes can make an analysis harder. Very large
changes, while popular with crypto novices, often do little or nothing
to improve security. The latter is known as "flailing", by the way,
and it seems to be quite popular with MIT students who are too clever
and yet not quite clever enough.

For example: Instead of using one of the standard, NSA-recommended
block cipher modes, the Kerberos designers invented their own
("Propagating Cipher Block Chaining"). Very clever. Of course it had
a subtle flaw, so they had to switch to the standard CBC mode in
Kerberos 5...

The point is that truncated SHA-1 has been analyzed by experts who
have produced a proof of its security (in terms of the security of
SHA-1 itself). Your XOR has had no such analysis. Neither has your
"modified AES-CTR" proposal, which example I notice you ignored.

I seriously doubt that Biham/Shamir/etc. are going to download the
Linux /dev/random source code and analyze it. So why not restrict
yourself to algorithms which the experts HAVE analyzed? Adding random
contortions on top of real crypto is like adding a screen door to a
bank vault.

 - Pat

P.S. The /dev/urandom question is really a different topic, so I will
respond in a separate message.

Relevant Pages

  • re:RFID tags and XOR
    ... everytime you start playing ... with messages it`s easily broken due to XOR, its security is crap. ...
    (sci.crypt)
  • Re: homomorphic encryption
    ... >I couldn't see how the requested property would contribute ... >to security instead of the opposite. ... here is a scheme that is homomorphic w.r.t. XOR and is ... The scheme can encrypt ...
    (sci.crypt)
  • XOR and ADD subtil difference ?
    ... I wonder if there is a "security" difference between XOR and ADD? ... let's take random-number generator using external entropy source. ...
    (sci.crypt)
  • 2.4 cryptoloop
    ... A week or so ago I asked if cryptoloop was support in 2.4 now that it has ... If I misunderstood that I no longer need to add an external crypto code, ... other than the insecure -E 1 (xor) mount. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)