Background: I'm building a .NET application, a very small part of this application allows for users to communicate with a third party application. I am designing this aspect. The third party simply needs the user name and expiry time (will likely be very short), because they have access to check, against our user store, if certain users are valid.

My plan is to use some sort of AES/RSA combination to do this. I have a certificate that I could pass, in private communication, to them for RSA decryption. Maybe do the following:

  1. Encrypt required info with RSA (using certificate)
  2. Encrypt this information with AES (append initialization vector to the end)
  3. Pass this to the third party
  4. Have them decrypt using the IV and private key I will give them (passed in private communications)
  5. Have them decrypt using RSA and the certificate

Am on the right track here?


  • 1
    It would be hard to answer this question in a competent way with this little information. All I can say is quite generic: Rolling your own crypto is an inherently idea. Stick with standards, e.g. take a look into things like SAML and XACML in your case. – Karol Babioch Mar 25 '14 at 23:52
  • 2
    It sounds like you're trying to reinvent TLS. – Stephen Touset Mar 26 '14 at 0:13

I think you should look at a more standard approach to store and forward, which is similar to the S/MIME encrypted email method. Take a look at PKCS#7 and XML Encryption standards.

These types of protocols work where the sender of the message looks up each recipient's certificate in the user store. The sender generates a symmetric key (AES is just fine) for encrypting the message, and encrypts the key using the public key of each recipient, which he now has in their certificates. The encrypted message and each recipient's copy of the encrypted AES key are bundled together and sent as a message.

In practice it is better to use RSA for key agreement and AES for bulk encryption.


RSA is asymmetric and based on complex mathematics. It is slow. The algorithm is not designed for speed. The algorithm is also limited in the size of what can be encrypted. The maximum message length which can be encrypted is the same as the key size. So for 1024 bit keys a maximum message size of 128 bytes, etc...

AES, and other symmetric algorithms, are designed for speed, efficiency and throughput.

Although key management is difficult, combining asymmetric and symmetric cryptography will allow you to agree keys and bulk encrypt.

  • A person inexperienced with cryptography should not be operating at the level of primitives like RSA and AES. There are far, far too many ways to make a catastrophic mistake and precious few to do it correctly. – Stephen Touset Mar 26 '14 at 5:02
  • Which is why I recommended using a standard technology like PKCS#7 or XML Encryption. Open implementations of these are available and hide the complexity of the technology. If you read my answer you will also realize that I don't recommend using raw encryption technologies. I just advise the most appropriate method of using them. – NRCocker Mar 26 '14 at 5:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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