Re: Running PGP on Netcom (and Similar)

[Adam Shostack <adam@bwh.harvard.edu>]

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.