Re: [Cfrg] matching AES security

[Brian Smith <[e-mail]>]

On Wed, Jul 30, 2014 at 5:33 AM, D. J. Bernstein <[e-mail]> wrote:
> These attacks assume that the attacker sees ciphertext for, e.g., an
> all-zero block encrypted under all of the keys. Sometimes protocols
> randomize their blocks to try to stop these attacks---but putting
> complications into protocols to compensate for a cipher's deficient
> security is _not_ a smart way to design a cryptographic system.

I agree that it would be better to not need to randomize blocks to
avoid the attacks you alluded to. However, it seems like randomizing
the blocks is often easy; for example, I think it would be pretty easy
to define AES-GCM and ChaCaa20-Poly1305 cipher suites for TLS in a way
where the initial nonce is comes from the PRF and then incremented.

Don't you think it is worthwhile to do such randomization anyway,
since the randomization acts as a second line of defense against a
variety of problems? Is doing so harmful in some way?

>    * the point that it's already common practice to combine, e.g.,
>      RSA-2048 with AES-128 and sometimes even AES-256, illustrating that
>      the users' performance constraints are the biggest issue;

I agree with this. I'd also like to point out that I've yet to hear
anybody say that the P-256 curve is too slow for them to use. I've
heard others say that it would be nice to have a faster curve like
Curve25519, and I've heard people say that it is important to replace
P-256 with a curve that we trust more like Curve25519 (for some value
of "we"). Curve25519 has kind of become the default choice since it
seems to meet both the "nice to have" performance criteria and the
"must-have" security criteria for many people.

However, as a thought experiment, imagine that we had a proof that
P-256 was secure (including a proof that the mysterious constant is
not a security issue). I think a lot of the urges to replace P-256
would vanish because P-256 performance isn't that bad and almost
everybody has an implementation. That, combined with the common sense
that computations per second will increase and attacks will improve,
makes me think that it makes more sense to standardize on a curve with
roughly the same performance of P-256 but with better security,
particularly if such a curve could cover multiple security levels
(128-bit and 192-bit) so that there is less need to rely on
negotiation mechanisms in protocols to select an acceptable curve.

I think it would make a lot more sense to standardize one
~192-bit-security-level curve than to standardize one 128-bit curve
AND one 192-bit curve AND one 256-bit curve just so we can say we've
"matched" security levels. I don't think "matching" is useful for many
applications, including in particular the use of TLS in web browsers
and similar applications.

It would be interesting to hear from people who could not use P-256,
Curve41417, or other curves of around the same performance level for
*performance* reasons.

Cheers,
Brian