[5737] in cryptography@c2.net mail archive
Re: having source code for your CPU chip -- NOT
daemon@ATHENA.MIT.EDU (Martin Minow)
Thu Sep 23 14:06:13 1999
Message-ID: <37EA6053.B98CA01F@pobox.com>
Date: Thu, 23 Sep 1999 10:16:03 -0700
From: Martin Minow <minow@pobox.com>
Reply-To: minow@pobox.com
MIME-Version: 1.0
To: Bill Frantz <frantz@netcom.com>, John Gilmore <gnu@toad.com>,
William Allen Simpson <wsimpson@greendragon.com>, cryptography@c2.net
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Steven M. Bellovin" wrote:
"Steven M. Bellovin" <smb@research.att.com> wrote:
>
> In message <v04210102b40f68d103d7@[63.193.122.223]>, Martin Minow writes:
>
> >
> > Yeah, but 370 Assembler H had a very extensive macro facility and
> > you could hide all kinds of wierd stuff in 370 code. Not too many
> > folk left around who can read it.
>
> And those of us who once could no longer remember how to -- for me, it's at
> least 20 years (more like 25, actually) since I touched the stuff...
> >
It's been 30 for me and I still have some listings lying around but
haven't the foggiest idea what some of the macros do (same for my
7090 assembler).
> That isn't the real problem -- most crypto routines per se are small enough
> that one could verify the machine code without too much effort. The problem
> is the environment they're embedded in. By that I mean not just the
> crypto-using application, but the entire operating system. By example, I
> could verify the machine code for IDEA, but not PGP and certainly not your
> favorite version of UNIX.
Why run crypto code on Unix? You could write a tiny microkernel
(semaphores, interrupt redirection, static memory allocation, no
memory management or protection) for a PDP-11 (or a similar "modern"
computer such as a 68HC11) in about 1000 lines of C and 200 lines of
assembler. (Or buy one ready-made from any of a half-dozen vendors)
Add a minimal IP stack and web server and you have enough of an
environment to write a complete "crypto machine" that can be verified
with a line-by-line code walk-through. Put the "crypto machine" in a
bullet-proof (and Tempest proof) container and "drive" it with HTML.
While you can't validate the Dallas Semiconductor TINI operating system,
it could serve as a test platform for a Java-based design. The crypto
secrets would stay on an iButton while the TINI provides the network
front-end. Both are programmed in Java.
Martin.
ps: I found Decus C on ftp://ftp.update.uu.se/pub/pdp11/decusc.tar.Z
It looks complete.
