Re: Secure voice software issues

karn@qualcomm.com (Phil Karn) sez-
 
> ...Finding a path through the PGP "web of
> trust" back to a trusted public key that the other party already has
> may be tricky. This is one thing that is much easier with a simple
> tree a la PEM, as you simply give the path back up to a common, shared
> root. 
> 
> I'm not sure how to do this with PGP. ...

Maybe this is a good service for a key server to perform.

Are there cases where you would want to endorse a key *privately*?
I.e., tell certain people only that you've met someone?

> If you first do Diffie Hellman and then immediately use the session
> key it generates to conventionally encrypt the rest of the protocol,
> including any RSA public key exchanges, this has the added benefit of
> denying passive eavesdroppers any information that would identify the
> parties to the call. The best an *active* eavesdropper (conducting a
> man-in-the-middle attack against Diffie Hellman) could do is to trick
> the parties into revealing their RSA public keys, and thus their
> identities.  But the parties would quickly discover this at the
> signature step, before the voice conversation actually starts.

What if you prepare RSA key pairs in advance in your computer's 
(phone's) spare time, then use one per conversation (at least for the 
initializing)?  You would encode your public key with the session 
private key, and a conventional key with your private key, in advance.
That would save time at the start of the conversation (although, to 
decode his keys would take two regular RSA steps.)

Am I wrong, or is Diffie-Helman only useful when you *don't* have
a way of verifying who each other are?

-fnerd@smds.com
quote me

> Am I wrong, or is Diffie-Helman only useful when you *don't* have
> a way of verifying who each other are?

No, DH is useful whenever you want to generate a session key between
two entities, and its even more useful because it doesn't require any
prior knowledge.  This means that you don't *need* to verify the
identity of the other person.  

However, without some way of verifying the key of the other party,
there is no easy way to detect a monkey-in-the-middle attack.  As was
put forward, a combination of DH to key exchange and RSA to detect
monkey-in-the-middle will protect you, but you lose your anonymity at
that point.

So, to return to your question, DH is useful even when you have a
method of verification.  So the answer to your question is yes, you
are wrong.

-derek

>Maybe this is a good service for a key server to perform.

Yeah, but that kind of assumes connectivity to the net. It's rather inconvenient
for a pair of phones who only have dialup modems connected to each other
to do this on every call.

>What if you prepare RSA key pairs in advance in your computer's 
>(phone's) spare time, then use one per conversation (at least for the 
>initializing)?  You would encode your public key with the session 

You could probably use temporary RSA key-pairs for each call, but RSA
key generation is notoriously slow. A lot slower than a Diffie-Hellman
key exchange.

>Am I wrong, or is Diffie-Helman only useful when you *don't* have
>a way of verifying who each other are?

Eh? No, as I've been saying, you can produce a very strong hybrid in
which both Diffie-Hellman and RSA each play an important part.
Diffie-Hellman generates the session keys, while RSA signs them.

Phil

> Eh? No, as I've been saying, you can produce a very strong hybrid in
> which both Diffie-Hellman and RSA each play an important part.
> Diffie-Hellman generates the session keys, while RSA signs them.

Does anybody *know* how existing secure phones do authentication?  I'm
familiar with the AT&T 3600, but I was wondering about a STU-III,
perhaps a Motorola SECTEL-1500, or equivalent Cylink. I assume that
they use Diffie-Hellman to exchange session keys, but what
public/private key info is stored in the phones (if any), and how do
you load it in?  Do you contact some kind of certifying authority to
download key info?  Is it stored in some kind of NVRAM, or EEPROM?
How many keys will the phone store?  I assume, given the presense of a
"zeroize" button that something useful is stored in the phone.  Also,
what is the "cryptographic ignition key"?  It is some kind of FLASH or
EEPROM?  What's on it? The key pair?

Thanks,
Eric Blossom