"Steven M. Bellovin" wrote:
"Steven M. Bellovin" <[EMAIL PROTECTED]> 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.
