1

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?

Thanks

Improve this question
2
  • 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
    Commented Mar 25, 2014 at 23:52
  • 2
    It sounds like you're trying to reinvent TLS.
    – Stephen Touset
    Commented Mar 26, 2014 at 0:13

1 Answer 1

Reset to default
-1

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.

Why?

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.

Improve this answer
2
  • 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
    Commented Mar 26, 2014 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
    Commented Mar 26, 2014 at 5:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .