Alex de Joode: | Timothy C. May (tcmay@netcom.com) did write: | | : Not that had Mr. De Payne been using PGP on Netcom, with his secret | : key stored there, the cops would have it. (The passphrase maybe not, | : depending on whether he stored _that_ there, too. And whether Netcom | : had logs of keystrokes entered, which strikes me as something they | : would probably have--we really need a "zero knowledge" kind of | : "reach-back" for remotely-run PGP.) | | Would a "challange response" type of verification do the "trick", ie | is it secure enough for passphrase monitering ? If the system is well designed. I sent the following to Phil Z. back in July to address exactly this problem. Hopefully, it will be in pgp3.
As a user of PGP for a while, there is a feature that I would like to see added to PGP 3, when that comes out. The enhancement would allow PGP to be used with an untrusted local CPU/network.
(Of course, I should have said 'untrusted network.' If the local CPU really is untrustworthy, you might be running a comprimised version of PGP, etc.)
To do this properly, you would want one shot passphrases, similar to S/Key. The implementation I see would have PGP hash your pass phrase some large number of times (say 1000, which takes less than a second on my 68030 mac) before using it to decrypt your pass phrase.
Then, when logged in from a line being sniffed, you would invoke PGP -1es ..., and when prompted for your pass phrase you would enter 800/something-ugly-that-md5-makes. PGP would then md5 this 200 times, and you'd have demonstrated your knowledge of your passphrase without ever sending it over a line. Clearly, PGP would need to store the fact that you had used #800, and only accept lower numbers.