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
participants (4)
-
Derek Atkins -
Eric Blossom -
fnerd＠smds.com -
karn＠qualcomm.com