--cNdxnHkX5QqsyA0e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2005 at 02:26:16PM +0200, Tonnerre wrote:
> On Tue, Jul 19, 2005 at 02:02:17PM -0700, Matt Thomas wrote:
> > 4) Allow various algorithms: SHA1, MD5, etc.
>=20
> Don't allow MD5! Also, SHA1 is a candidate that shouldn't be trusted just
> like this. Why?

What do you recommend for an algorithm for this purpose?  The purpose
Matt stated was essentially a read-verify.  Implied requirements are
something that takes relatively little code space and something that's
unlikely to return the same value for a section corrupted by a bad read
(from disk or network?) as it would for a correctly-loaded section.

The threat model, if you want to call it that, sounds like it's random
hardware failure, not a malicious entity.

I think both md5 and sha1 fit those requirements and the threat model.
They're also already in libkern.

>  - people might use it
>  - people might decide to use it for security relevant functions

This sounds a lot like, "Don't buy a light-duty drill because
someone might decide to build a skyscraper with it.  You need to
get the Milwaukee Hole Hawg for all your drilling needs."

I fully agree that MD5 should not be used for any applications that
are designed to protect against malicious people.  I don't know that
it's invalidated for all applications.

In any case, I'm interested in hearing what you recommend.

Thanks,
-allen

--=20
                  Use NetBSD!  http://www.NetBSD.org/

--cNdxnHkX5QqsyA0e
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFC3k0utbG21IdtLQIRAtyuAKC6Vy9UlJmsqrfAuDT7yKMnKbtWWQCgwNHa
MFtn6Y6GNASx04OjVKZvdd4=
=H+Pd
-----END PGP SIGNATURE-----

--cNdxnHkX5QqsyA0e--