Back in the early 90's I lead a team that developed a complete DES based
security sub-system for the HP3000 that was fully NIST certified.  It
included file or field encryption, decryption, MAC signed, and
authenticated.  It also did onetime password challenge/response and came
with a complete 3 level Key Management Agent (KMA).  The company,
Racal-Guardata, did all DES based work in custom built hardware called a
Crypto-Server which was connected to the 3000 via a separate LANIC.  Each
Crypto-Server had a unique key in them and if the box was tampered with in
any way the memory was flashed.  The manual key encrypting key, automatic
key encryption key, and automatic data encrypting key where encrypted with
the Crypto-Server key and stored on the 3000 but they were never in the
clear.  The only time they were decrypted was when they were inside the
Cypto-Server and about to be used.  The 3 levels of keys for each
relationship where configured in the KMA to be replaced on a regular bases.
Typically the data keys were changed weekly so even if you found a current
file, the keys used to encrypt it were only valid for a week (although you
could decrypt with an expired key for one additional week).  The onetime
password was in the form of a challenge / response and required a handheld
token that was also armed with a unique key that was stored inside it and in
the Crypto-Server.  All data to and from the 3000 is in the clear, including
passwords, so this minimized that concern.  The challenge was in the form of
a 7 digit random number, generated with a NIST certified random number
generator inside the Crypto-Server and the response was different from each
token because of its key.  Even if the challenge and response where
"sniffed" the likelihood that somebody pretending to be that user would get
the exact same challenge was pretty small and repeated failures would
deactivate the user id.  The sub-system has a full API for programmatic
interface, a stand-alone utility, and a logon interface.
        Sadly the only company interested it was the one that funded the
multi-million dollar development project and the application was never
resold.

Thanx,
  Jonathan (Jon) M. Backus, MPE-CSM ~ President
  Tech Group ~ 15 Catawba Place ~ Hagerstown, MD ~ 21742-6515
  Email: [log in to unmask] ~ AIM: JMBackus
  Vmail: 301.988.0614 ~ Fmail: 301.714.1854
  Web: www.TechGroupMD.com


-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of Gavin Scott
Sent: Tuesday, August 14, 2001 10:17 PM
To: [log in to unmask]
Subject: Re: Encrypting disc files.


Wirt writes:
> However, it's important to note that encrypting files on a host
While there are many problems to be overcome if one wants to create securely
encrypted files on one's computer, the fundamental weakness of encryption in
general is *not* one of them.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *