Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

2017-02-14 Thread Atul Luykx
Why is that 2^48 input blocks rather than 2^34.5 input blocks? Because he wants to lower the security level. The original text recommends switching at 2^{34.5} input blocks, corresponding to a success probability of 2^{-60}, whereas his text recommends switching at 2^{48} blocks, corresponding

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

2017-02-14 Thread Atul Luykx
Hey Quynh, When someone says AES-128 has 128 bits of security he or she means that 2^128 AES operations will break the cipher with probability 100%: finding the key and the plaintext. The claim is stronger: regardless of the number of plaintext-ciphertext pairs available to the adversary, it

Re: [TLS] Randomization of nonces

2016-08-16 Thread Atul Luykx
On 2016-08-16 07:51, Watson Ladd wrote: On Mon, Aug 15, 2016 at 9:56 PM, Martin Thomson wrote: On 16 August 2016 at 09:46, Paterson, Kenny wrote: Sadly, you can't implement XGCM using an existing AES-GCM API, because of the way the MAC

Re: [TLS] Randomization of nonces

2016-08-16 Thread Atul Luykx
Right now I see no reason for this not to work. In fact if you XOR the tag as well, then every block cipher call looks similar to a DESX call, like in XCAU. Atul On 2016-08-15 21:56, Martin Thomson wrote: On 16 August 2016 at 09:46, Paterson, Kenny wrote: Sadly,

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

2016-07-13 Thread Atul Luykx
will be good enough in practice. However, it's important to be clear about the risks involved in venturing into unknown territory. Atul On 2016-07-13 13:14, Dang, Quynh (Fed) wrote: Hi Atul, On 7/12/16, 3:50 PM, "Atul Luykx" <atul.lu...@esat.kuleuven.be> wrote: To be clear,

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

2016-07-12 Thread Atul Luykx
To be clear, this probability is that an attacker would be able to take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential (but incorrect) plaintext, and with probability 2^{-32}, be able to determine that this plaintext was not the one used for the ciphertext (and with probability

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

2016-05-15 Thread Atul Luykx
Here's a possible re-write of the second paragraph: Nonce re-use in AES-GCM results in failure of both confidentiality and authenticity. Not only will confidentiality be breached by leaking the XOR of any two packets processed under the same nonce, but TLS sessions can also be attacked

Re: [TLS] Data Volume Limits Analysis

2016-04-29 Thread Atul Luykx
Hey Martin, You're right, this analysis works for any block cipher with 128 bit output that is "good enough" (a pseudorandom permutation), and so for all versions of AES regardless of the key size. Determining the appropriate key size for the block cipher relies on accounting for possible