Hello Perry E. Metzger, since you wrote:
> [EMAIL PROTECTED] (Hey, that's me) says:
> > Hello Jun Mao, since you wrote:
> > > Some users require for transfering files i.e. cp,...
> > The short answer is: put the ecryption into the presentation layer of the
> > network, that is where it belongs - see any good book on Networking, for
> > example A.S.Tanenbaum [Computer Networks, Prentice Hall] ...
>
> There is strong evidence that the network layer may be more
> appropriate -- see the recent IP security proposals.
Well, they would say that, wouldn't they ? As TCP/IP does not contain a
formal presentation layer, I would not expect IP security proposals to
suggest that that is where encryption belongs. It would mean declaring it
to be Somebody Else's Problem. After all TCP is really transport layer, but
contains presentation layer stuff (e.g. end of line mapping in ftp).
Encryption of course needs to be done after end of lines are mapped to
network representation (normalization), decryption before denormalization
(mapping network representation to local representation). In between is the
right place for compression and decompression, as decently encrypted data
will prove incompressible.
This does not preclude further encryption at (just above) the network
layer. The whole argument about verification could be slotted in here, see
Jerry Saltzer's paper on it (See Tanenbaum where to find that).
The argument against locating encryption at level 3 is that the security
would be completely at the mercy of the transport provider, which, if an
outside agency, trashes the whole concept.
Take for example data passed over ISDN lines, running over an ATM backbone.
Should you just trust the telco that it will encrypt data ? What happens to
missed or out of sync data blocks ? If you say they will not happen, the
telco will already provide a reliable (i.e. transport) service, and you
would no longer have control over network layer encryption. If these
corruptions do happen, they will neatly kill any cbc encrypted data.
But do send me further references for the IP proposals. I do not really
want to rehash other peoples' arguments from scratch.
> Public key encryption and appropriate network databses fix that.
> However, this is going far afield of the topic.
Is that a database of network entities and appropriate network access
methods, a reincarnation of CODASYL databases (see the seminal work by
C.J.Date on Relational Databases), or one with multiple independent
maintenance points like X.500, which needs a network just to justify the
expense.
> However, I'll point out that the MIT kerberos utilities have an
> encrypted authenticated rcp already written for you, and this should
> likely solve the stated problem nicely.
Hmm, just train the users to do only The Right Thing (TM) ...
N.B. Public Key encryption (like in RSA) and symmetric encryption (like in
DES) are cryptoanalytically equivalent when applied to networks. I leave
stating the exact prerequisites as an exercise for the reader.
Thomas
* email: cmaae47 @ imperial.ac.uk (uk.ac.imperial on Janet)
* voice: +44 71 589 5111 x4937 or 4900 (day)
* fax: +44 71 823 9497
* snail: Thomas Sippel - Dau
* User Support Services
* The Center for Computing Services
* Imperial College of Science, Technology and Medicine
* Exhibition Road
* Kensington SW7 2BX
* Great Britain
