GeezerVison

Is there a mechanism behind picking "80" or just expedience for having it produce the right outcome?
(The geometric mean of 64 and 128 is roughly 90, FWIW...)

Is there a mechanism behind picking "80" or just expedience for having it produce the right outcome?
(The geometric mean of 64 and 128 is roughly 90, FWIW...)

ssl_security_default_callback() calls ssl_get_security_level_bits() which has a minbits table.

I picked the value we use for everything else that is security level 1. As far as I can tell, we only use 80, 112, 128, 192 and 256 for strengths. I didn't check too hard.

I've no objection to making it 90. I don't know if any code depends on it being one of the standard values. I'd be quite surprised if somebody somewhere didn't write this kind of rubbish:

switch (strength) {
case 80: ... break;
case 112: ... break;
case 128: ... break;
case 192: ... break;
case 256: ... break;
}

I prefer the solution in #16160 to be honest. But this is more data driven.

I prefer the solution in #16160 to be honest. But this is more data driven.

On first look I do, as well. But I cannot claim to have spent the time to properly review either approach.

I've also pushed a new commit changing the strength to the more accurate 90 bits.
Happy to drop this part if it is controversial.

I've also pushed a new commit changing the strength to the more accurate 90 bits.
Happy to drop this part if it is controversial.

Why is 90 bits strength more accurate?

@kaduk, do you have a reference for the strength?

Using the geometric mean, AES-256-CCM8 would have a strength > 112 bits and would stay at security level 2.

"geometric mean" was just an attempt to backsolve how one might justify 80 bits on its own right (as opposed to just happening to trigger the desired threshold based on the current logic in the other parts of the code).
I don't think I have a reference for CCM8 strength that would give an answer larger than 64 bits.
https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/ is in some senses even less optimistic about CCM8...

One possibility is to just put it at 64 bits which is at least justifiable. Although it would mean it goes into security level 0 instead of 1. That would have meant that it is not available in the default security level any more - except for the fact that we just voted to increase the default security level to 2 anyway - so either way it won't be available in the default security level. So the distinction between 0 and 1 might not matter that much anyway.

I've switched them to 80 bits again. Going to 64 bits breaks tests. I'll investigate and reduce the strength if I can fix things.

I've lowered the security level to 64 bits and fixed the test failures.
Re-review required.

Comments addressed.

Merged, thanks for the feedback and discussion.