Re: [TLS] Unifying tickets and sessions

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

There are, obviously, two things a server should be able to use for a
unified session id/ticket:

 - An opaque identifier
 - Encrypted session state using a construction like RFC 5077's.

Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
HMAC-SHA256 with a 256-bit key.

Or, uselessly high 256-bit security against active attackers, and
uselessly low 128-bit security strength against global passive
adversaries.

There should be a recommended session ticket construction at a 256 bit
security strength for privacy to replace RFC 5077 s.4's.

--

On Wed, Oct 22, 2014 at 8:56 AM, Hubert Kario <[e-mail]> wrote:
> That assumes that you have the space to store all those communications,

I frankly don't understand this.

According to the newspapers, at least, the NSA *does* store *all*
encrypted communications pending eventual decryption. So evidently
they do, at least.

> then you need to have the ability to reference all those 2^50 keys in close to real time.

This is a few petabytes of data, or a few thousand 1 TB SSDs. This is
not a large amount of data.

> Yes, it doesn't require "hard" computation, but it does require massive
> amounts of relatively fast memory.

No. It doesn't. It requires less than one cipher block per key for
most of the computation. (The main expense is memory bandwidth.)

> It's a classic memory-time tradeoff, isn't it?

No. The gains are better than linear. See
http://cr.yp.to/snuffle/bruteforce-20050425.pdf, but for "circuit"
read "graphics card/SPU/MIC".