2
$\begingroup$

Bob know's Alice's public key, and he wants to make sure he's connecting to the one which has that key. Furthermore, Alice wants to verify when she gets a connection from Bob who'll give his public key that he is indeed the one who has that key.

Bob will send Alice half the AES private key and half the initialization vector which he generated randomly, both encrypted using Alice's public key.

Alice would reply by sending back what Bob sent + the other half of the AES private key and the initialization vector which she generated randomly as well.

Afterwards communication begin using AES crypto stream with a key composed of the two halves both exchanged. If a crypto exception was thrown at either side at any point, the connection will be terminated. No third message will be sent from Bob to Alice to verify that he got her part of the key, the AES stream will begin directly after Alice's message.

Note: I thought about using Diffie-Hellman, but what I didn't like what that the private key agreed upon would be the same for every session assuming the two parties will not change their public keys.

Is this enough for both to verify that each one is the actual owner of the claimed public key, and to exchange the AES symmetric key safely without creating potential security issues ?

Improve this question
$\endgroup$
6
  • $\begingroup$ Thank you so much for replying. Can you please elaborate a little bit ? I thought only Bob will know Alice's part of the key, and only Alice will know Bob's half ? An eavesdropper would have to know Bob/Alice private keys to be able to decrypt the transmitted portions of the symmteric key ? ie: Eve must know Alice's private key to know the half of the symmetric key Bob transmitted to Alice using her public key ? $\endgroup$
    – xander
    Mar 9, 2013 at 11:37
  • $\begingroup$ Ah, sorry, I did not see that the keys were encrypted with each other's public keys. Ignore my last message. If you already know each other's public keys, then yes, there should be no problem. But there are a few practical issues (not security, but usage). I'll let others elaborate. But I don't quite understand why you don't want to use DH. The shared secret obtained from DH changes for every session, even if you keep the same group parameters. $\endgroup$
    – Thomas
    Mar 9, 2013 at 12:47
  • $\begingroup$ Thank you so much for your time. to be honest I am not sure how to go about implementing DH, the one link I found was about C# ECDiffieHellman msdn does not indicate that the key would be different for each session. It just showed each user using the public key of the other one to generate the shared key, and thus I assumed it would have to be unique. Do you see where/if there is randomness in ECDiffieHellman ? Or if there is a better DH library for C# ? $\endgroup$
    – xander
    Mar 9, 2013 at 13:02
  • $\begingroup$ The randomness comes not from the group parameters, but from the $a$ and $b$ individual secrets of each party, which are selected randomly. Then the shared secret is $g^{ab}$ which is therefore unique to each session. The Wikipedia article is pretty good, if you haven't read it already (though I recommend not to implement it yourself). I cannot help about the C# implementations, though. $\endgroup$
    – Thomas
    Mar 9, 2013 at 13:19
  • $\begingroup$ But to change the secret keys I have to change the public keys as well, right ? If so then I guess I am better to go with RSA, because I want the public keys to be as some sort of global identifiers for the connecting parties and remain unchanged so the parties could find each other again only using the public keys, yet to use diff symmetric keys per session. Makes sense ? tbh I never implemented a crypto system before, thats why I want to make everything using ready-made libraries w/ very minimal coding from my part. $\endgroup$
    – xander
    Mar 9, 2013 at 13:30

1 Answer 1

Reset to default
3
$\begingroup$

You are inventing your own protocol. Don't do that! You're likely to get something wrong.

Instead, use SSL. You can use SSL with a server cert and a client cert. That solves exactly this problem; each party can verify the public key of the other end of the communication and verify they're talking to who they want to talk to. If everything checks out, they have a secure connection they can use for their communication. It solves the problem, and it has been vetted far more thoroughly than anything you invent yourself ever will be.

Improve this answer
$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.