> From: owner-openssl-us...@openssl.org On Behalf Of David Schwartz > Sent: Monday, 21 September, 2009 19:48
> Peter Wilkes wrote: > > > so we ran this with a 64 bit int and noticed that 128 bits > comes out. > > can we safely ignore the other 64 bits? why are we getting > 128 bits out? > > > > we are using the TripleDES cipher. > > It's not clear if you mean 128-bits comes out of the > encryption process or 128-bits comes out when you decrypt it. > (128-bits of ciphertext? Or 128-bits of recovered plaintext?) > > If the former, that's normal. It's pretty easy to prove that > any encryption scheme that guarantees the output is the same > size as the input will have various pretty serious > limitations, so it's not unusual for encryption to expand > data. (For a silly example, consider a single bit that > encodes whether or not to do something. Someone need only > observe one communication and see whether or not you do that > something to be able to 'break' the cipher. One that expands > the single bit to, say, 128-bits non-deterministically would > not have that problem.) > Although commonly used symmetric padding (PKCS5) doesn't address this. It is deterministic. Its only function is to allow variable length (by octets) plaintext in modes like ECB and CBC which must encrypt/decrypt whole blocks. Instead CBC, and OFB, CFB, CTR use an Initialization Vector (IV) which is random (or at least unique) and transmitted or stored in addition to the ciphertext. It can be just prepended to the ciphertext, making the ciphertext one block bigger; or it can be handled as a separate item, making the overall message, file, etc., that much bigger. (ECB doesn't have any good way to prevent duplicate-recognition, and that's one of it's well-known long-established weaknesses.) *Asymmetric* schemes like OAEP for encryption and RSAPSS for signature do include randomness directly in the primitive. > If the latter, that indicates a poor choice of padding or > cipher mode. If you know the original plaintext is always, > say, 64-bits, you should be able to ignore all the rest. But > it's probably a better idea to choose a padding scheme that > protects the length. Definitely. And a standard one, unless there's very good reason to do otherwise. The standards have been widely analyzed; something you invent hasn't. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
