Re: [Cfrg] matching AES security

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

> To answer Uri’s question, yes, this attack requires a shared known plaintext
> block across all the connections.  This is most likely to happen through the
> use of CTR mode with a deterministic nonce; or the MAC of the empty string; or
> explicit key confirmation.
> 
> Also, the attack is not realistic for AES-128 in the near future, and we don’t
> have to warn users about it.  But it’s more realistic than a 128-bit key
> exhaustion.

Good points! I concur.

> But even in a single-target model, you can’t just compare the brute-force
> security levels of, say, AES-192 and NIST-P384.  Brute force is not a
> realistic threat to either one.

Again, I concur. But still, we need some ways to compare, e.g., NIST-P384
with NIST-P521. You cannot say "beyond bit-length X they're just all the
same".

> Instead you have to consider the risk that an attacker with a given budget can
> hack you.  This risk would encompass things like:
> 
> * Value of the keys.  The long-term ECC keys are worth more.

Yes.

> * Protocol tightness.  Time/memory/data attacks are not necessarily limited to
> multiple-user attacks, and are likely to weaken AES more than ECC.

Don't know. Maybe.

> * Chosen-plaintext are more likely to affect AES.

Probably the opposite. Easier to mount against AES, but AES is more immune
against them.

> * Quantum computation.  More bits of AES buys you more resistance, but more
> bits of ECC does not.

Yes.

> * Mathematical breakthrough.  Hard to quantify.

Yes. :-)

> * Side channels.  More bits don’t buy you much more security.

Yes. :-)

> My conclusions from this would be:
> 
> * Past 192 bits of security, brute force security ratings are basically
> meaningless even with linear time/data tradeoffs.  Stronger ciphers are mostly
> a hedge against breakthroughs.

OK, agree.

> * We use 256-bit AES because it’s not much more expensive than 192-bit AES.

Actually I don't know why we don't use 192-bit AES. Maybe you're right.

> * We should consider a more-than-384-bit elliptic curve if and only if it’s
> not much more expensive than a 384-bit curve.
> * There’s not much point to ed-512-mers if it costs twice as much as
> ed-384-mers.

See your point about "a hedge against breakthroughs". We don't know if a
breakthrough would be made against ECC, and if it would – whether it would
be hampered "enough" by more bits, and how many more bits would be needed to
stay "safe".

So while a scalable quantum computer (probably) obliterates ECC, there could
be mathematical advances that are less drastic. I.e., there could still be
reasons for larger curves to stay around.

> * The unusual-sized curves Curve41417 and Ed448-Goldilocks should be
> considered if and only if they’re not much more expensive than the 384-bit
> alternatives.  This has been demonstrated for Goldilocks, which is 6% slower
> than ed-384-mers on Sandy Bridge.  I believe that it will also be true for
> Curve41417, but so far I’ve only heard numbers for Cortex A8 NEON, and none of
> the alternatives have optimized implementations on that platform.

Don't know.