Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread Raphael Jacquot
On Sep 10, 2013, at 6:43 PM, Nemo n...@self-evident.org wrote: GET / HTTP/1.1\r\n is exactly 16 bytes, or one AES block. If the IV is sent in the clear -- which it is -- that is one plaintext-ciphertext pair right there for every HTTPS connection. In fact, _any_ aligned 16 bytes of

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread Perry E. Metzger
On Wed, 11 Sep 2013 06:49:45 +0200 Raphael Jacquot sxp...@sxpert.org wrote: according to http://en.wikipedia.org/wiki/Padding_(cryptography) , most protocols only talk about padding at the end of the cleartext before encryption. now, how about adding some random at the beginning of the

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread Jerry Leichter
On Sep 11, 2013, at 5:57 PM, Nemo n...@self-evident.org wrote: The older literature requires that the IV be unpredictable (an ill-defined term), but in fact if you want any kind of security proofs for CBC, it must actually be random. Wrong, according to the Rogaway paper you cited. Pull up

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread Nemo
Jerry Leichter leich...@lrw.com writes: The older literature requires that the IV be unpredictable (an ill-defined term), but in fact if you want any kind of security proofs for CBC, it must actually be random. Wrong, according to the Rogaway paper you cited. Pull up

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread Nemo
Jerry Leichter leich...@lrw.com writes: The real problem is that unpredictable has no definition. Rogaway provides the definition in the paragraph we are discussing... Rogoway specifically says that if what you mean by unpredictable is random but biased (very informally), then you lose some

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-10 Thread Jerry Leichter
On Sep 10, 2013, at 5:49 PM, Perry E. Metzger pe...@piermont.com wrote: Phil Rogoway has a paper somewhere discussing the right way to implement cryptographic modes and API's. It would be useful to get a URL for it. In particular, he recommends changing the definition of CBC...to E_0 =

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-10 Thread Jerry Leichter
On Sep 10, 2013, at 12:43 PM, Nemo n...@self-evident.org wrote: GET / HTTP/1.1\r\n is exactly 16 bytes, or one AES block. If the IV is sent in the clear -- which it is -- that is one plaintext-ciphertext pair right there for every HTTPS connection. Phil Rogoway has a paper somewhere discussing

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-10 Thread Perry E. Metzger
On Tue, 10 Sep 2013 17:04:04 -0400 Jerry Leichter leich...@lrw.com wrote: Phil Rogoway has a paper somewhere discussing the right way to implement cryptographic modes and API's. It would be useful to get a URL for it. In particular, he recommends changing the definition of CBC from: E_0 =

Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-10 Thread ianG
On 11/09/13 01:36 AM, Jerry Leichter wrote: (Generating a different one for this purpose is pointless - it would have to be random, in which case you might as well generate the IV randomly.) In a protocol I wrote with Zooko's help, we generate a random IV0 which is shared in the key