Re: [TLS] Unifying tickets and sessions

[David Leon Gil <[e-mail]>]

On Wed, Oct 22, 2014 at 11:16 AM, Viktor Dukhovni
<[e-mail]> wrote:
> On Wed, Oct 22, 2014 at 10:27:32AM -0400, David Leon Gil wrote:
>> There should be a recommended session ticket construction at a 256 bit
>> security strength for privacy to replace RFC 5077 s.4's.
>
> The same construction works just fine with AES-256-CBC, so it is
> merely a matter of updating the draft to recommend AES-256-CBC for
> the encryption.

Yep.

> (I've updated the Postfix default ticket cipher
> to AES-256-CBC as planned for the next release).

This is really excellent to hear. :)

--

The rest is, strictly speaking, irrelevant to session tickets. Unless,
that is, you believe that 128 bits is a reasonable level of protection
for TLS master secrets.

> With somewhat less than 2^25 seconds per year, we're looking at ~2^23
> or ~8 million years of output from such a plant.

Right now, a gigawatt buys you roughly 2^77 linpackflops / year (see
Green500). (I get roughly the same number of symmetric crypto block
ops / year for that hardware -- mostly from the GK110s.)

And by 2020, the top 500 supercomputers will be doing about 2^88
linpackflops / year. See http://www.top500.org/statistics/perfdevel/

(Note that it's undesirable to search the full 2^128 keyspace in any
event; efficiency goes down once you've gotten most of the keys.)

> The use of random IVs or similar "whitening" makes pre-computation substantially less effective.

There's no precomputation. (Storage costs during the attack are <1
block for CTR/GCM, 1 block for ECB, and < 2 blocks for CBC and CFB.)

Ryan: There's very little point in performing this attack with a
quantum computer for TLS; solving dlog is much easier. (Also, the
D-wave thing is not a quantum computer.)