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:
| 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

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."