On Monday, November 11, 2002, at 12:31 PM, Oscar Batyrbaev wrote:

> I agree with Jeremy. I'd love to see that artwork as well one day :).
> The main
> reason I suggested MD5 is that Craig wanted to save bytes. I proposed a
> significantly safer way to do it vs. 8 bytes that would _pass_ an
> audit today (all
> is needed when you look at the tall pickets :)) where as "8 bytes" way
> has a less
> chance of doing so and more complicated to design correctly.

If he just wants to save bytes, then he is better off truncating a SHA1
hash. If you are space constrained, there is more security in a
truncated SHA1 hash than an MD5 hash. Period.

>
> PS: to the other post - of course birth day on 128 bits is not
> practical but it is
> on 64 bits - that is one of the reasons why MD5 size is 128 bits. Also
> many
> algorithms were discarded after diff. analysis - but IIRC after they
> were done on
> the *full* algorithm. DES was/is in use even after diff. analysis
> attacks on some
> _truncated_ version were found - kind of similar to MD5 attacks
> situation.

No, there are plenty of algorithms that have been thrown away without a
full break. The best known attack against 3DES doesn't raise any cause
for alarm, but the best known attacks against a bunch of the AES
competitors have led to those algorithms not being used, even though I
don't believe any of them have seen a *practical* break. Continuing to
use DES isn't a very good idea. Just because people are using it
doesn't make it a secure solution. I know plenty of people are still
using ciphers that XOR with a fixed key, but that doesn't mean you
should be recommending it. As for 3DES, there is nothing wrong with
it. In many ways, it is one of the more conservative choices around.

However, it would be foolish to recommend MD5, particularly for new
applications. Again, why impose any more risk than you need to impose,
when there's a better solution readily available? Especially since
the odds are really pretty good that there are people out there who can
break MD5? As I said in response to Jeremy, depending on your threat
model, the weakest link in the chain quickly becomes the crypto rather
quickly if you take the right measures. For example, if you're only
worried about attackers from the net, you can just give everyone
random, securely chosen passwords, and require their use. The trick of
increasing the cost of a single digest computation also does very well
against "crack" based attacks. If you're checking for trivially
guessable passwords (with something like cracklib) and then add a
second or so of computation, a brute force attack becomes pretty
infeasible.

John

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]