Re: RNG for Padding
Mr Pink writes: In Applied Crypto, the use of padding for CBC encryption is suggested to be met by ending the data block with a 1 and then all 0s to the end of the block size. Is this not introducing a risk as you are essentially introducing a large amount of guessable plaintext into the ciphertext. Is it not wiser to use RNG data as the padding, and using some kind of embedded packet size header to tell the system what is padding? Back in 2001, there was a discussion of the general issue of altering data structures to avoid known plaintext on sci.crypt, under the subject of Known Plaintext Considered Harmless. A surprising diversity of opinions were expressed. http://groups.google.com/group/sci.crypt/browse_thread/thread/f1aae3a2d10dbcd4?tvc=2q=known+plaintext+considered+harmless Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG for Padding
We had many discussions about this 15 years ago You usually have predictable plaintext. A cipher that isn't strong enough against a chosen/known plaintext attack has too many other protocol problems to worry about mere padding! For IPsec, we originally specified random padding with 1 trailing byte of predictable trailing plaintext (the amount of padding). Together with the (encapsulated) protocol number, that actually made 2 bytes of predictable trailing plaintext. Due to my work in other groups, everything that I've specified afterward uses self-describing-padding. That is, the last byte indicates how much padding (just as before), but each byte of the padding indicates its position in the padding sequence. 0 ::= never used. 1 ::= 1 byte of padding (itself) 1 2 ::= 2 bytes of padding ... The original impetus was hardware manufacturers of in-line cipher devices, that don't usually have a good source of randomness. Also, this provides a modest amount of integrity protection. After decryption, the trailing padding must be the correct sequence. Of course, this should be in addition to integrity protection over the whole packet! Additionally, this avoids a possible covert channel for compromised data, whether by accident (revealing a poor RNG or the current state of the RNG), or trojan process communication. Note that I've said avoids, as varying the amount of padding would give a lower bandwidth channel for the latter. When designing, it's always best to defend in depth. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RNG for Padding
Hi, This may be out of the remit of the list, if so a pointer to a more appropriate forum would be welcome. In Applied Crypto, the use of padding for CBC encryption is suggested to be met by ending the data block with a 1 and then all 0s to the end of the block size. Is this not introducing a risk as you are essentially introducing a large amount of guessable plaintext into the ciphertext. Is it not wiser to use RNG data as the padding, and using some kind of embedded packet size header to tell the system what is padding? Thanks for your suggestions, Mr Pink - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG for Padding
| Hi, | | This may be out of the remit of the list, if so a pointer to a more | appropriate forum would be welcome. | | In Applied Crypto, the use of padding for CBC encryption is suggested | to be met by ending the data block with a 1 and then all 0s to the end | of the block size. | | Is this not introducing a risk as you are essentially introducing a | large amount of guessable plaintext into the ciphertext. | | Is it not wiser to use RNG data as the padding, and using some kind of | embedded packet size header to tell the system what is padding? It's a requirement of all modern cryptosystems that they be secure against known-plaintext attacks. This is for two reasons: 1. The state of the art being what it is, it's no harder to create a system with decent security guarantees (within the limits we have *any* such guarantees, of course) with security against known-plaintext attacks than without. 2. More important: History has shown that there's *always* known plaintext available. There are tons of situations where you know what is being sent because you actually have access to the same information from other channels (once *everything* is encrypted, much of what's encrypted isn't in and of itself secret!); other situations where you can force the plaintext to some value because, for example, you provided it; yet others where you don't know for sure, but can make good guesses. So the additional security is minor. Note, BTW, the the 1 and then all 0's padding lets a legitimate receiver determine where the data ends; random padding doesn't. So you'd have to send the length elsewhere with random padding. That length would have a limited number of possible values - becoming easily guessable plaintext. -- Jerry | Thanks for your suggestions, | | Mr Pink | | - | The Cryptography Mailing List | Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] | | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG for Padding
On Fri, 7 Mar 2008 15:04:49 +0100 COMINT [EMAIL PROTECTED] wrote: Hi, This may be out of the remit of the list, if so a pointer to a more appropriate forum would be welcome. In Applied Crypto, the use of padding for CBC encryption is suggested to be met by ending the data block with a 1 and then all 0s to the end of the block size. Is this not introducing a risk as you are essentially introducing a large amount of guessable plaintext into the ciphertext. Is it not wiser to use RNG data as the padding, and using some kind of embedded packet size header to tell the system what is padding? Maybe -- but you probably have enough guessable plaintext elsewhere that a bit more simply doesn't matter much. See, for example, my 1997 paper Probable Plaintext Cryptanalysis of the IP Security Protocols, http://www.cs.columbia.edu/~smb/papers/probtxt.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
