I'm developing a SOAP application where java clients provide authentication information with each call, and the server verifies the auth info before dispatching calls.
- The length of this auth info will typically be 50 bytes.
- Approximately half (the leading half) of these auth info bytes will be different with each call.
I want to encrypt this auth info each time the client makes a soap call, I was thinking of using RSA: the client encrypting the info using the public key and the server decrypting using the private key.
Q. I understand that RSA (asymmetric) is slower than symmteric but would this still be the case given the size of the plaintext
Q. Is using RSA to encrypt small packets in-secure?, if so should I artificially increase the size of the plaintext by introducing random noise?
If you do this, use a padded scheme to get proper random noise in there. I don't think you have a choice not to under Crypto++ 5.1, but I could be wrong. Just use a good RNG (not any form of rand()), like the ones supplied.
Q. If I instead use a block cipher (say AES) should I use a different IV for every encryption, if so the client would have to send the IV (and the length of the IV) along with the ciphertext?
IMHO that degree of volatility is unnecessary and will not save you. The likely attack on this form is middle man and changing the key that frequently is not going to help you if you transmit it to the server. What are you trying to protect against? If you are trying to protect against a rogue executing bogus calls then just sending up new AES keys will not save you. I recommend you generate a session AES key per client and send it to the server by encrypting it using your RSA public key.
Q. Would Base64 or Hex be the best encoding option to use to transmit the cipher text via soap (HTTP/XML) to the server?
Base64 will certainly keep your bandwidth lower since it is 4:3 instead of 2:1 on your upstream byte count.
HTH. michael
comments appreciated. phil
