Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:30 ADT
Eric Young (eay@cryptsoft.com)
Fri, 17 Jul 1998 11:41:58 +1000 (EST)
On Thu, 16 Jul 1998 mgraffam@mhv.net wrote:
> Don't do any kernel code in assembler. The linux kernel runs on far more
> than just ix86. Do it in well-written C that will be portable, and
> compatible across architectures.
I would make a few sugestions.
- Design your code to accept any cipher via some regularised API (even
if the cipher to be used is specified at compile time via macros).
requirements will change over time and you should probably not hardwire
in any particular crypto library function names (unless it is mine :-).
You probably want to stay out of the 'my XYZ implementation is faster
than yours' argument, so avoid relying on one particular library.
- If you are going to support different ciphers,
make sure to record on the encrypted disk a reference to the encryption
algorithm being used. Since the standard encryption operation would be
'encrypt/decrypt 512 bytes' going through one level of function
pointers will not hurt and again will suport different algorithms easily.
- How about making the ciphers loadable modules? Again, depending on
the cipher used on a disk, dynamically load the module.
My main interest in encrypted partions is for ZIP and JAZ drives where
you have 100m+ removable disks with >1meg/sec transfer rates (scsi).
I would like to be able to have the kernel modules I need on a
non-encrypted partition of this disk. I have not played enough with
the linux kernel, but it would be an easy way to support hardware devices
etc. It would also be nice for encrypted CDs to hold their own cipher
modules.
- Don't be obsesed with performance. Get it working and let others
worry about the assember implementation of a particular cipher/CPU.
Which cipher to use is a religious issue, so try to avoid it in preference
to getting something actually working :-).
For a pentium pro 200, on 1024byte encryptions, I currently get
des-cbc 4,630,000 bytes/sec
des-ede3 1,653,000 bytes/sec
rc5-32/12-cbc 14,010,000 bytes/sec
blowfish-cbc 7,122,000 bytes/sec
cast-cbc 7,100,000 bytes/sec
on this same box, the 3 IDE drives transfer data at 3.8, 2.13 and 6.25
MB/sec The 100meg ZIP scsi drive does 900k/sec. With a reasonable amount
of memory, I build SSLeay at about the same speed on the ZIP drive as the
IDE. What I'm trying to say is that disk latency/transfer rates/memory
caching mean that any cipher doing 2meg/sec is probably fine (assuming
the cached pages are not encrypted). It would be an interesting
paper to see what the performace impact would be....
> Don't limit yourself to twofish, either: its a new algorithm and if
> I was a betting man, I might bet that all is well with Twofish .. but
> security and privacy ought not be a gamble.
Follow the IETF lead, go with a default of a free concervative cipher
(triple-DES in outer CBC mode) and allow optional loading of other ciphers,
depending on religious affilations.
eric (attempting to remain agnostic :-).
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:30 ADT