Is There a Name for This Algorithm?

[wswartzendruber]

I came up with a way for two parties to agree on a common symmetric encryption key over an open channel. It uses asymmetric encryption to do so. I want to know who, if anyone, came up with this first.

Let us suppose we have two parties: Jake and Bob. They want to establish a symmetric key over an open channel.

Jake's public key: j_pub
Bob's public key: b_pub
Jake's random stuff: j_rand
Bob's random stuff: b_rand

So first they would exchange public keys.

Jake >> j_pub >> Bob
Jake << b_pub << Bob

Then they would each generate some random crap and encrypt it with the other guy's public key, and send it.

Jake >> bpub(j_rand) >> Bob
Jake << rpub(b_rand) << Bob

Each party decrypts with their private key what they got. So now they both know what was generated on the other end. Next they take what (they think) was originally generated on the other end, and encrypt it with the other guy's public key, and send it.

Jake >> bpub(b_rand) >> Bob
Jake << rpub(r_rand) << Bob

And now each party should get back what they had both originally generated. These two random blobs could be concatenated into a symmetric cipher.

QUESTION: Assuming this is indeed secure, is it called anything?

[John R. Graham]

Not secure.

• First issue. Susceptible to the classic "man in the middle" attack. Just for example, Eve intercepts Jake's and Bob's communications. When Talking to Jake, Eve pretends to be Bob; when talking to Bob, she pretends to be Jake. She can carry out the key exchange on both ends and sit in the middle with full access to encrypted communications.
  
• Second issue. You've left out anything that proves to Jake that he's actually talking to Bob and vice versa.

However, what you're describing is similar to the key exchange protocols use by SSL/TLS and others. I don't know if it has another name. To secure the key exchange protocol, do the following:

• Use certificates instead of bare public keys. The certificate attests that the owner of the public key you're receiving owns (i.e., can wield) the associated private key.
  
• Establish trust in the exchanged public key certificates. For example, each party can check the certificates against a well known certificate authority (e.g., Verisign, CAcert). There are other ways to establish trust but this is the most traditional.
  
• Sign the encrypted random number messages. This proves that they came from who you think they came from.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[avx]

Uhoh, did Alice have a sex-change?
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

[John R. Graham]

Hee hee. Think so.

• Alice and Bob
  
• Responsible Behavior

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[wswartzendruber]

I knew it didn't verify authenticity. But I also discounted the man-in-the-middle being able to take control. I limited his powers to only seeing the exchange.

[depontius]

I don't know if you're already familiar with it, but there is another algorithm with a name that does something like this - "Diffie-Hellman key exchange".
_________________
.sigs waste space and bandwidth