> From: owner-openssl-us...@openssl.org On Behalf Of Jeremy R. > Sent: Monday, 27 July, 2009 23:19 (Sorry I was out.)
<snip other points> >> Another idea: you're not using the benefit of PKC encryption >> (unknown to one). Why not just symm-encrypt the data? <snip> > Well, envelopes do have the benefit that it's only the symmetric key > that's encrypted, so it shouldn't be that slow to decrypt the 32 bytes > for the symmetric key. It's only one RSA (or precisely RSA+scheme eg OAEP) operation, yes. The cost is the same for any amount of data encrypted up to the limit. But the cost of any large-pubexpt op is significantly greater than small-pubexpt (because small) OR privexpt (using factors/CRT). In fact, I see rsa/rsa_eay.c explicitly rejects public ops for expt>64bits modulus>3072bits presumably for this reason. Although I don't know (and didn't go to the effort of researching) how long ago these values were set; they might be due for a "COLA". > But yes, if I would have to create a second key pair anyhow, I may simply > create a shared symmetric key instead - the signature should be enough to > prevent forgery (right? I think that's the point of signatures). The _function_ of a digital signature is to prove that certain data came "from" (at least via) a particular, usually identified, party or multiple parties; for a PK signature, a party is defined as a private-key holder. This can be usable for several things: - data not changed (tampered) after it was signed - messages all from same source, even if pseudonymous; possibly sequenced - message(s) not created (forged) by someone other than the signer(s) - signer(s) can't later repudiate messages (sometimes) As I understand your situation you want the clients to not accept data that isn't actually from your server. That's one straightforward and common use for signature. > By the way, as far as IVs go, I'm currently generating a random IV > and tacking that onto the beginning of the message, which I believe is > fairly common. Is there anything wrong with this? Should I be using a > static IV (I would think that would be less secure, but I'm not an expert). Yes, a static IV would be less secure. Depending on the "mode" (e.g. CBC, CTR, etc.) IVs should always be unique = different for each message (within the same key, but you are holding the key static); for some modes they should ALSO be unpredictable by the adversary. Random choice is good for both -- over a large enough space it has negligible probability of repeating, and if properly done it should not be predictable. A note, however: if you are using software randomness (as most do), just calling the default in many programming languages (including C/C++ and Java) is usually easily (enough) predictable and thus not good for the second criterion above, and often too small for the first criterion as well. Java has a separate SecureRandom. openssl exposes its RAND_* module as well as using it internally, but you should make sure it's adequately seeded before using it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
