[13212] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: The Pure Crypto Project's Hash Function

daemon@ATHENA.MIT.EDU (Bill Frantz)
Tue May 6 12:11:01 2003

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20030506012757.A98017B4D@berkshire.research.att.com>
Date: Mon, 5 May 2003 21:31:41 -0700
To: "Steven M. Bellovin" <smb@research.att.com>
From: Bill Frantz <frantz@pwpconsult.com>
Cc: EKR <ekr@rtfm.com>, Ralf Senderek <ralf@senderek.de>,
	"cryptography@metzdowd.com" <cryptography@metzdowd.com>

At 6:27 PM -0700 5/5/03, Steven M. Bellovin wrote:
>Except, of course, that coding in assembler is quite demonstrably more
>bug-prone.  And I'm not even talking about productivity (also lower) --
>bugs are a major source of security holes.

As long as you don't try to claim that the C family is a high level
language, I'll agree.  (I still think my assembler code from the old days
had fewer bugs in released code than my current C code.  Of course that
just may mean that I've lost my edge to old age.  Or that, knowing the
risks, my testing was much more thorough.)


>As for matching the output of the compiler -- well, it's not often that
>I get to cite my dissertation, but that's what I worked on >20 years
>ago.  See http://www.research.att.com/~smb/dissabstract.html for the
>abstract.

<paranoia> How do you trust the program proving equivalence? </paranoia>

I think I agree with Eric:

>Sure, but this isn't practical for building all but the simplest
>applications. In my view, the downsides of having things be
>inconvenient in order to make them amenable to this kind of proof far
>outweigh the downsides of having usable systems which you cna't prove
>to be correct.

However, we must recognize that in taking this approach, we are building on
a foundation of sand.  The reason I like Ralf's approach is because he is
trying to minimize the amount of sand.  (OTOH, his implementation of that
approach has a multitude of problems, as others have noted.  Trusting
Perl/Python is only one.)

I am reminded of a conversation with the National Computer Security Center
contractors who were helping us when we were considering evaluating KeyKOS
under the Orange Book criteria.  We asked them about the microcode in the
IBM disk controller.  They essentially shook their heads and didn't want to
address the problem.  (BTW - KeyKOS was never evaluated because we couldn't
find a VC willing to invest on the order of $1M to generate paper for the
government.)

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | Due process for all    | Periwinkle -- Consulting
(408)356-8506         | used to be the         | 16345 Englewood Ave.
frantz@pwpconsult.com | American way.          | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post