Subject: Re: Verifying a kernel.
To: Tonnerre <tonnerre@thundrix.ch>
From: Allen Briggs <briggs@netbsd.org>
List: tech-kern
Date: 07/20/2005 10:49:14
--St7VIuEGZ6dlpu13
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2005 at 03:16:53PM +0200, Tonnerre wrote:
> SHA1 can be used with care, still. SHA256, SHA384, SHA512 and SHA768
> are good candidates.

These seem like overkill to me for this application, but part
of the specification was to allow for different algorithms.
I'll note that we don't appear to have SHAxxx in libkern at
the moment, but we do have SHA1, MD5 and MD4.  It looks like
NIST doesn't have examples/tests for SHAxxx, just SHA1.

> > The purpose Matt stated was essentially a read-verify.
>=20
> Did you think about people who might get the idea to use it for a differe=
nt
> purpose?

Yes, but I don't find it terribly relevant.  I would expect
documentation to accompany the code to discuss what's being
used and what the goals are.  If you have different goals,
a different goal will almost certainly want a different
solution.

If you want to protect against tampering, I'd probably want
to use a totally different approach.  Anyone who can update
the image with flipped bits could also update the checksums.

I think it's reasonable to consider the fact that someone
could try to use the code for purposes other than what's
intended.  I just don't see that it justifies overdesigning
for this application.

CRC32 might be reasonable, but the likelyhood of a collision
is somewhat higher.

> Then they read, it uses MD5, and say, oh, great. And then they make
> assumptions they shouldn't make

I think Gavan addressed this.

> You would agree that if you build a door lock that should only assure that
> the door keeps closed, and is prone to being opened using lockpicks, peop=
le
> might get the idea that it secures their doors, which is wrong.

If it's described as a lock and not as a latch, then sure.  But if
someone's looking at an unlabelled object and decides it's a lock,
that's a bit different.

-allen

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

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

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

iD8DBQFC3mRqtbG21IdtLQIRAmPPAJ94htlYBMiXJEYGosawB+YiZRDRHQCg5A83
h9+nE0QFiYEn0Xq6SgWkvgo=
=Bz9F
-----END PGP SIGNATURE-----

--St7VIuEGZ6dlpu13--