Confirming my understanding: panic on assert seems appropriate because otherwise we have UB.

References must never be null, so they can't be made from a null pointer.

This assert isn't strictly necessary as long as the function is always given non-null pointers.

I thought it's better to be extra careful about this, I don't feel strongly about this choice. It could have been a Result (assuming null is a real possibility), or downgraded to debug_assert if we trust that we'll never get a null pointer in these functions.

I don't understand this safety requirement. It's not clear what "initialized" here refers to, since this is an init function doing initialization.

I was conflating documentation between this and session resumption. Removed and removed the unsafe.

again not clear what "initialized" is

I was conflating documentation between this and session resumption. Removed and removed the unsafe.

Only length of the key needs to be checked, right? The iv is an array of max len.

Is there a cheap way to check key length against the Cipher to make it a safe function?

In raw_ticket_key the key is assumed to be 16 bytes long. Why is one place fixed, and another is flexible?

Addressed in 2d5be20

Only length of the key needs to be checked, right? The iv is an array of max len.
Is there a cheap way to check key length against the Cipher to make it a safe function?

Yea good point. We can do a key.len() != cipher.key_len() and return early. But not sure if ErrorStack::get() is correct error to return here.

In raw_ticket_key the key is assumed to be 16 bytes long. Why is one place fixed, and another is flexible?

raw_ticket_key is dealing with key_name, which is guaranteed to be 16 bytes (docs).

Here, the application is calling EVP_EncryptInit_ex with the correct key and iv, the sizes of which depend on the chosen cipher.

I also expanded the tests to use the iv and key_name values from the callback.