So I'm trying to use RSA-AES to encrypt a JSON and SOAP payload.
For JSON it seems straightforward:
auto-generate a symmetric AES key
AES-encrypt the payload with that
RSA-encrypt the AES key with the RSA Public Key.
Concatenate the two ciphertexts to the receiver.
For decryption, the receiver splits the two ciphertexts (based on length),
then uses the RSA Private key to decrypt the AES key from the first part,
and uses the resulting AES key to decrypt the second part, to receive the original plaintext payload.
But I'm not familiar with SOAP, How do I go about concatenating two ciphertexts in a SOAP payload?
Related
I have messages I need to be able to encrypt when being sent. They should only be able to be decrypted by the receiver.
Initially, I had a structure where the message is encrypted using the receiver's public key, and the receiver then uses their private key to decrypt their messages. However, since I was using RSA, the size of the message was quite limited.
I'm imagining two potential solutions, but am not quite sure how to implement the better one (option 2).
(Easy) just split up each message into many smaller parts, encrypt and store those. This would only change the query structure of my app but not the encryption structure.
I could encrypt the messages with symmetric keys, which is faster and works on any size. However, I would then need to encrypt that symmetric key with an asymmetric one. The problem then becomes that I can only decrypt the symmetric key when the asymmetric private one is provided, ie when the receiver wants to read their messages. So in that case, how would I actually encrypt the messages? Since I don't want the sender to be able to access a key used for decryption as well.
The problem then becomes that I can only decrypt the symmetric key when the asymmetric private one is provided, ie when the receiver wants to read their messages. So in that case, how would I actually encrypt the messages?
That's simple, you use an ephemeral, message specific, fully random symmetric key for data encryption before you encrypt it with the public key. Preferably you should explicitly destroy the symmetric key after that. You can prefix the wrapped (encrypted) symmetric key before the ciphertext of the message, as it will always have the same size in bytes as the modulus (i.e. the RSA key size in bytes).
The system you are thinking about, which is much better than splitting up messages for RSA, is called a hybrid cryptosystem. There are various other ways to accomplish the same thing such as RSA-KEM and - for elliptic curves - ECIES. Both are not often present in crypto-libraries though.
If you decide to use RSA/AES for sending cryptograms then I would advice you to use OAEP and e.g. AES-CTR rather than AES-CBC as RSA PKCS#1 v1.5 padding and CBC padding are both vulnerable to padding oracle attacks.
It is highly recommended to sign the messages, otherwise an adversary can encrypt fake messages. Encryption is only used to achieve message confidentiality, not message integrity & authenticity. An adversary may even try plaintext oracle attacks if any message can be send. If you are not allowing a set of private keys that you control then you should sign-then-encrypt, not encrypt-then-sign.
And as always, prefer TLS or other explicit secure transport protocols if that's an option for transport security.
I have a public 2048 bits RSA Key in byte array, I need to encrypt some data but I don't want to encrypt it directly with the public key. I can generate a common symmetric key such as AES to encrypt my data. I want to then encrypt my symmetric key with my public RSA key. I know what I need to do I just know how. I tried converting the byte array to PublicKey object but I get Invalid Key Format Exception. Is there any other way I can make it work? I am using BouncyCastle as my security provider.
I'm trying to set up a bidirectional encryption scheme between a client and server using the OpenSSL crypto API.
I have generated an RSA public/private key pair for the server. I wanted to use the EVP_Seal/Open functions to generate a symmetric key to be used for session encryption. The client uses the public key to encrypt a symmetric key and send it to the server using EVP_Seal. The server then uses EVP_Open to decrypt messages... but how do I now encrypt messages to send back to the client?
I don't actually have access to unencrypted the symmetric key, so I can't make calls to EVP_EncryptInit and the like. How do I encrypt information to send back to the client? I was under the impression I was generating a bi-directional symmetric key with these functions, but I can't figure out how to use it.
I considered sending a second symmetric key that I just generate myself (using, say, RAND_bytes) as a "message" that the server could then decrypt, but it seems like I should be able to use the symmetric key that was already generated instead of making a new one.
I also considered using the encrypted symmetric key output from EVP_Seal as my actual symmetric key and passing that as the message for the server to use for encryption, but that also seemed really weird and incorrect.
I am planning on file encryption during file transfer from physical storage to physical storage as my final year project at my high school.
My question is, can AES Encryption and RSA Digital Signature Scheme be used as file encryption? Currently I am focusing on text files (.doc, .txt).
I've got the following protocol in mind:
the file will be encrypted using AES Encryption
the private key from RSA Encryption will be the signature for the file
the public key will verifies the signature during decryption
I am not sure about the bit sizes of the keys to use, either 256 bit AES and 1024 bit RSA.
Most of the time AES and RSA are used together in the following way:
create an asymmetric key pair and keep the private key confidential and the public key in a trusted keystore
create a symmetric data encryption key and encrypt the data with it (e.g. using AES-CBC and a random IV)
encrypt the symmetric data encryption key using the public key of the key pair
create a signature with a private key (if possible, using a separate key pair), using e.g. PKCS#1 using the SHA-256 hash algorithm
store the encrypted data (+IV), the encrypted key and the signature
To verify
retrieve the data etc.
verify the signature using the public key from the trust store
decrypt the symmetric key using the private key (protected by a password, stored on an USB stick or smart card etc)
decrypt the data
You will need some way to store the data. It's best to use a common format for this such as Cryptographic Message Syntax. For key sizes see http://www.keylength.com/ e.g. using the NIST or ECRYPT II recommendations. I would suggest matching sizes, e.g. AES-128 bits, RSA 3072 bits and SHA-256 for the signature.
I need to implemented security for client-server communication. I have implemented the following hybrid cryptosystem
To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following:
Obtains Alice's public key.
Generates a fresh symmetric key for the data encapsulation scheme.
Encrypts the message under the data encapsulation scheme, using the symmetric key just generated.
Encrypt the symmetric key under the key encapsulation scheme, using Alice's public key.
Send both of these encryptions to Alice.
To decrypt this hybrid ciphertext, Alice does the following:
uses her private key to decrypt the symmetric key contained in the key encapsulation segment.
uses this symmetric key to decrypt the message contained in the data encapsulation segment.
I am using RSA For a public-key cryptosystem, and AES for symmetric-key cryptosystem. Every thing works fine, but I am not sure how to handle AES initialization vector. Currently, I am concatenating the AES key and initialization vector encrypting it with the public key and sending that to server.
I just wanted to get some opinions about this approach. How this problem is solved by other communication protocols SSL etc.
Thanks.
You don't encrypt the IV. Bundle it with the encrypted key and send it (in the clear) to the recipient.
Standards for this do exist. This scheme is called "KeyTransRecipientInfo" in CMS (upon which S/MIME is based), and PGP offers a similar mode. TLS also includes the initialization vector as a parameter in the key encryption algorithm identifier, using the same ASN.1 syntax as CMS. A robust, open-source library to perform this operation is available for many, many platforms.
At the very least, studying the CMS specification might help avoid some of the many pitfalls in a home-brew implementation. See §6.1 and §6.2.1 of RFC 3369.
I've done the same thing, and I handled it the same way - concatenate the AES key with the IV and encrypt them both.
You could also just send the key and use the key itself to generate an IV - for example by using the first 128 bits of a hash of the key as the IV. That should be OK security-wise as long as you are generating a new AES key for each session and not re-using the same AES key over and over with the same IV.
There is no reason to encrypt the IV - you can send that in the clear. Just make sure you pick a new one each time (the same way you do the AES key).
That said, it is often convenient to package the AES key and IV together. Encryption of 16 bytes ain't that expensive.