Re: Running PGP on Netcom (and Similar)
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 ? : I just don't think the dangers are worth it. All the theoretical hot : air about whether kestroke timings are "random enough" is moot if : Netcom is turning over records to investigators. : --Tim May -- ____ Alex de Joode <usura@xs4all.nl> \ /__ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- \/ / "It's dangerous to be right when the government is wrong." \/ --Voltaire --finger usura@xs4all.nl for PGPpublicKEY--
Alex de Joode writes: ...
: 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 ?
Well, I iused the "reach-back" term in a vague way, to suggest an avenue...it may not be the correct term. We need a system where a user, Alice, computes *something different every time*...a conventional "challenge-response" is not good enough, as anyone monitoring the line or having access to the logs can then impersonate Alice. Zero knowledge interactive proof systems offer such a thing...in fact, password schemes are one of the applications that have been written about. Maybe in PGP 4.0.... --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."
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.
On Mon, 12 Sep 1994, Adam Shostack wrote:
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.
I can see how this gets around the problem of sending cleartext passphrases over a network, but how does it help stop the problem of the remote system running a keystroke log that is handed over to the authorities during a bust? Armed with 800/some-number they can just type the same thing into PGP (or a modified copy) and decrypt the files that you were keeping on-line. Regards, - Andy +-------------------------------------------------------------------------+ | Andrew Brown Internet <asb@nexor.co.uk> Telephone +44 115 952 0585 | | PGP 2.6ui fingerprint: EC 80 9C 96 54 63 CC 97 FF 7D C5 69 0B 55 23 63 | +-------------------------------------------------------------------------+
| > > 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. | I can see how this gets around the problem of sending cleartext | passphrases over a network, but how does it help stop the problem of the | remote system running a keystroke log that is handed over to the | authorities during a bust? Armed with 800/some-number they can just type | the same thing into PGP (or a modified copy) and decrypt the files that | you were keeping on-line. If they are logging everything, then they have the output of your PGP-decryptions. Unavoidable. If all they have is the 800th md5 of your passphrase, then they have a $10m route of attack. PGP will reject the 800th+ md5 of your passphrase. They need the 799th or lower to get your key. The 800th will be rejected by PGP as already used. (It would have to be hashed into your keys somehow to avoid the attackers from just resetting the number. They might be able to do that with backup tapes, old copies of your keys, etc.) This addresses some attacks; those based on network sniffing. Attackers with more resources, such as law enforcement, are inconvinienced, perhaps greatly, but not thwarted. J. Random Cracker using network sniffing is thwarted, and I think that in itself is worthwhile. Adam
This discussion is ridiculous. If you can crunch keys on your own trusted machine, why not just run PGP there? Or at least the RSA secret key operations? I've been saying for a long time that there is a role for the latter device. It would hold your PGP secret key and do all RSA secret key operations (signing, decryption) locally, taking requests from and communicating the results back to hosts running PGP that do the rest: RSA public key operations such as signature verification and encryption, and IDEA encryption/decryption. Ideally this device would be a smart card, but a small palmtop might make a good prototype (except for speed). The big win is in much better protection of the RSA secret key; it would never have to leave the device, except perhaps in encrypted form for backup. By plugging this device into a (possibly hacked) host you could use your RSA key without risking all of the traffic you have ever protected or will protect with a particular RSA secret key if that particular host happens to be compromised. But any traffic that passed through the hacked host would still be compromised, as it would if the link between the secret key device and the host were tapped. There's simply nothing you can do about it. Phil
participants (5)
-
Adam Shostack -
Alex de Joode -
Andrew Brown -
Phil Karn -
tcmay＠netcom.com