Cache constants for fetched EVP_cipher

[slontis]

Checklist

• documentation is added or updated
• tests are added or updated

[richsalz]

much gain for few lines of code; nice!

[beldmit]

Is it safe enough to cache flags? I'm not familiar with the provider code so are the cached values cached per implementation?

[slontis]

The values that are cached here are equivalent to values that were in the old const EVP_CIPHER structs.. i.e- they are constant default values that should not change. The flags should be treated in the same way as the key_length (i.e this is the constant default key length).

[beldmit]

I'm not sure about flags because some of them can be implementation-defined (e.g. EVP_CIPH_FLAG_FIPS).

[slontis]

The values have been stored into the EVP_cipher during the fetch operation as they need to exist before either the new_ctx method or the ctx_int have been called.

e.g- it needs to handle the sequence
ciph = EVP_CIPHER_fetch(.....)
len = EVP_CIPHER_key_length(ciph)

[slontis]

I'm not sure about flags because some of them can be implementation-defined (e.g. EVP_CIPH_FLAG_FIPS).

Well that particular one is a dead flag left over from the old fips module.
If you want values that change then they belong in the ctx.
i.e: EVP_CIPHER_CTX_set_flags()

[t8m]

This changes the semantics so that all the ciphers have to support all these cached constant parameters. However IMO that is actually a good thing. We could even add to documentation that these cached constant functions cannot fail if we wanted to make life of application writers easier.

[paulidale]

@t8m, I don't think it changes the semantics quite like that: a cipher that doesn't know/support one of the cached parameters won't return it from the get query and it will default to zero. True, the unsupported return code won't happen anymore.

It would be an easy enough change to keep the unsupported return code, if that is preferable.

I like the idea of all ciphers supporting all of these constants. I do wonder what the IV length for an ECB mode cipher should be. Unsupported seems more reasonable than zero.

[levitte]

Why do you want to distinguish an unsupported IV length from zero? Is there a practical reason?

[paulidale]

It's the first example of a change that sprung to mind -- agreed, it isn't a good one 😴

This does represent a (small) change of behaviour which is the issue.

[levitte]

Actually, this gets us back to pre-3.0 behavior, no?

[paulidale]

@levitte, did you intend to approve this? It is still missing an OMC approval....

[paulidale]

Replacing @slontis (for review purposes).

[levitte]

@levitte, did you intend to approve this? It is still missing an OMC approval....

I was too quick on the labeling... but since you approved, all's good.

[p-steuer]

merged.

master: 3c957bc