4
$\begingroup$

I'm fairly new to encryption, so I wanted to check the logic for a .net solution I'm working on that encrypts data between two parties. the receiving (decrypting) party will have an RSA key pair stored. They will transmit the public key to the encrypting party via a web service call. The encrypting party will use the public key to encrypt a random generated password. Prior to the RSA encryption, this password will be used to derive the Key/IV (using Rfc2898DeriveBytes) for RijndaelManaged symmetric encryption for the main data.

The RSA-encrypted password will be transmitted along with the RijndaelManaged-encrypted data via another web service call. The receiving party will decrypt the RSA password using their private RSA key. They will then use the password to decrypt the RijndaelManaged-encrypted data.

The thinking is that the use of the random password will avoid the pitfalls of storing a constant password if I were to only use symmetric encryption. It also provides for a different key/IV each time as well as a different RSA key each time. The reason I'm thinking of this Symmetric/Asymmetric hybrid approach is after reading about some of the performance pitfalls of just using RSA. My question is whether this is any better or worse than going with one encryption method or the other, or if I'm missing something that will make this approach impossible or open me up to some sort of vulnerability.

Improve this question
$\endgroup$
11
  • 2
    $\begingroup$ The method is insecure unless the encrypting party has some way (currently unstated) to verify that the public key used for encryption matches the private key of the intended decrypting party. Also, there is no attempt to authenticate the origin of the data that the decrypting party will obtain. $\endgroup$
    – fgrieu ♦
    Commented Nov 17, 2015 at 18:25
  • 1
    $\begingroup$ No. An attacker could generate a public/private key pair, then do just the same. $\endgroup$
    – fgrieu ♦
    Commented Nov 17, 2015 at 19:37
  • 3
    $\begingroup$ Nope. Known solutions involve transmitting the decrypting party's public key over a channel assumed to offer integrity; reading a hash of that public key over such a channel; trusting a third party to certify the decrypting party's public key. $\endgroup$
    – fgrieu ♦
    Commented Nov 17, 2015 at 21:09
  • 1
    $\begingroup$ What's proposed in the question has at least an advantage over symmetric encryption: it is safe against passive eavesdropping of exchanges. $\endgroup$
    – fgrieu ♦
    Commented Nov 18, 2015 at 5:42
  • 2
    $\begingroup$ Why are you using passwords at all? You could encrypt the key (and optionally the IV) with RSA. $\endgroup$
    – CodesInChaos
    Commented Nov 18, 2015 at 11:13

1 Answer 1

Reset to default
4
$\begingroup$

The concept of using an asymmetric key (RSA) to encrypt a symmetric key (AES) is not new. This was first popularized by PGP, which is probably what I would encourage you to use to solve your problem. SSH (well SFTP in particular) also uses a somewhat similar approach and could also be pressed into transmitting files securely.

Pretty much any approach you could dream up would suffer from the problem of the establishment of initial trust. In general, you probably don't want to constantly regenerate the asymmetric keys as then you have to also regenerate the trust for them.

One of the simplest ways to handle initial trust for a program/automation is to establish it yourself by supplying the same PSK (pre-shared key) on both (or all) ends of a connection. If you did that, then you have a different problem, of keeping the shared secret secure. There are devices that can do that for you, such as HSM (hardware security module) but they are frequently expensive. (The cheapest one that comes to mind is $500US from Yubico.)

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Heck, if you just have a shared secret between the nodes there is a much simpler implementation: you could just generate a random value and use it as the input to a secure hash (such as SHA256) along with the file metadata (file size, date/time and a hash of the unencrypted file to prevent tampering) and the PSK to generate a key for your file encryption. You transmit the random value and the file metadata to the other end along with the file, and remote end uses the PSK along with the received data to recalculate the correct file decryption key. $\endgroup$
    – P Holder
    Commented Nov 19, 2015 at 4:25
  • $\begingroup$ Thanks, I'll look into PGP. For the other suggestion, do you mean if I were able to store the xml of the public key on the encrypting server? Would it be safe to use the public key to generate the random key for the encryption then use the private key on the decryption server to retrieve the random key value? If the data that needed to be encrypted was small, could i just use the public key to encrypt it, or would it still be advisable to generate a random key? $\endgroup$
    – Skintreesnail
    Commented Nov 20, 2015 at 14:41

Your Answer

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

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