0

I've successfully exchanged keys using DiffieHellman and now wanted to use those keys to encrypt the object I need to send across the wire using RSA encryption.

DiffieHellman gives me the actual key so:
Question #1
Is there a way to import the actual key directly into a RSACryptoServiceProvider variable?

It seems I can only find examples of importing XML based but those have extra info that I do NOT get from DiffieHellman (like for Public keys, the XML carries the Exponent value, and for Private key the XMLS carries P,Q,DP,DQ,Inverse ...which none of those are provided by the DiffieHellman)

Question #2
What would be the right way to combine the DiffieHellman private/public keys provided into an RSA based encryption call so that the calls encryption/decryption would work across the wire on both ends?

SF Developer
  • 5,244
  • 14
  • 60
  • 106
  • Related: https://stackoverflow.com/questions/23167936/generating-aes-key-after-ecdh. With Diffie-Hellman you exchange a symmetric key, not one to be used with RSA etc. – Perseids Jul 30 '14 at 07:10

1 Answers1

6

Diffie-Hellman allows two parties to agree a mutual key over an insecure channel. Such a key would then normally be used to encrypt/decrypt the data using a symmetric algorithm (e.g. AES).

The DH-agreed key cannot be used as RSA key, as RSA keys have a specific construction requiring prime numbers that is not shared by a DH-agreed key, and even if it was, RSA uses distinct public and private keys, whereas DH agrees a single shared key. You would also not use RSA for the main data encryption anyway, as it's significantly slower than modern symmetric algorithms.

One way you might combine them would be if RSA was used to sign the key exchange to provide authentication and protect against a man-in-the-middle attack, since DH on its own does not provide authentication.

Iridium
  • 23,323
  • 6
  • 52
  • 74
  • If I then use EAS encryption, since the shared secret key is unique for each customer and in specific my case, just for a set block of client api requests (shared secret keys expire every 60 seconds) ...could the IV be fixed for ALL clients? I read that IV can be public too. If so, is this an OK approach or a truly secured approach? – SF Developer Jul 30 '14 at 21:16
  • 1
    @SDDeveloper - No, the IV *must* be different for every plaintext encrypted, as this ensures that two identical plaintexts encrypted using the same key result in different ciphertexts. – Iridium Jul 31 '14 at 06:00