In <9402041825.AA27913@media.mit.edu> you write: [Some items of interest to C-punks include CERT's advocacy of stopping cleartext transmission of password (no shit sherlock), and their proposed solutions, including the use of one-time passwords which I had queried about on this list a few months back. Of course they don't mention any sort of real encryption, let alone PGP. How hard would it be to build in PGP security to the transmission layer of something like FTP? Seems like a fairly simple problem, given that any site which supports anonymous FTP can publish a public key. Even if we assume that encryption would slow down the file transmission too much, we could still use it for the login/authentication part of the session... --AW] Since the command channel is flat ascii, one could extend the protocol with a pgp-password command, which would send the password encrypted in the server's public key. Similarly one could use the sort of convention that the wu-ftpd does to request encrypted files... simply request file.pgp, just like you request file.z, file.gz, etc. Of course, there really *ought* to be an RFC for it, but I'm thinking something like a command 666 PGPL -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- which would send an encrypted login and password. The other piece to hack up would be the ftp client, it would have to ask for your login/password on the ftp server host, then crank that through pgp, and send an ELOGIN command down the socket -- no problem. The big issue, in my mind, is how the ftpd is going to get the key to unlock the *system's* private key... Do you compile it into the code? Should ftpd ask for it when it comes up? Marc