Subject: ed(1) encryption.
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: David Burren <davidb@eyrie.werj.com.au>
List: current-users
Date: 03/19/1994 11:43:15
Sorry to keep harping on, but while we're on the subject of encryption...

ed(1) mentions that its "encryption/decryption is done using the bdes(1)
algorithm".

What is bdes(1)?  Is this yet another thing ripped out of 4.4?  Is a
description of its operation/syntax available?  With that, a shell
wrapper around ed could easily provide the same function, or the whole
thing could be implemented "from scratch".  The point is that rather than
defining a new interface, I'd prefer to use an existing one.


For that matter, why is ed exportable and bdes not?  Or is it that with a
dummy libcrypt bdes is useless and thus no-one bothered?  As non-US libcrypts
are freely available, this should no longer apply.

It could be a hairy question: if DES isn't exportable, does that also apply
for code that calls DES subroutines and implements various encryption modes
(such as the CBC mode used in ed)?  Does this fall into the broad umbrella
of "enabling technology"?

If someone decides "yes", then this code (or at least some significant part
of it) should be added to libcrypt and not exported.  This shouldn't be a
problem, as I can implement the same functionality in FreeSec and maintain
seamless operation.


Thoughts anyone?  A description of bdes(1) and/or its history would be a
start.  And before anyone says that user-level file encryption isn't a
useful tool, I'll comment that while it has limitations, it IS a useful
component of a broader suite of tools.

- David B.

& I hate politics! &

------------------------------------------------------------------------------