Re: [TLS] About encrypting SNI

[Brian Sniffen <[e-mail]>]

Andy Lutomirski <[e-mail]> writes:

> On Thu, Apr 17, 2014 at 9:35 AM, Sniffen, Brian <[e-mail]> wrote:
>> On Apr 17, 2014, at 9:52 AM, "Andy Lutomirski" <[e-mail]> wrote:
>>>
>>> , Bob can decrypt it in time t(N), and an eavesdropper
>>> who does not know any of the private keys can't distinguish the
>>> message from random?
>>
>> Surely the eavesdropper can measure the decryption delay, probe himself, and discover which key it was---unless every implementation carefully shuffles keys?
>>
>> And now an adversary can cause N decryptions per initiated connection. Ouch.
>
> If N == 4 and the decryption operations are fast, this isn't so bad.

Cryptographic negotiation attacks are already one of the most powerful
DDoS techniques available.  Making them 4x more effective is lethal.
Unless we want to say they're so dangerous as to be no *more* lethal
from quadrupling, this isn't okay.

I hesitate to ask, but: is it plausible to re-open the proof-of-work
conversation, so a server under load can, in the initial opportunistic
encryption phase, push back to a client and ask for a puzzle to be
solved?

> I wonder if there's a way to test a large number of private keys at
> once.  If so, then the cost drops to O(log N).  Off the top of my
> head, I can't think of a cryptosystem with that property.

I certainly don't expect to find any *pair* of cryptosystems with that
property, and continue to maintain that in 3 years we won't find two big
organizations willing to use exactly the same crypto.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies