Am 05.12.21 um 18:33 schrieb Gert Doering:
Hi,
On Wed, Dec 01, 2021 at 07:07:21PM +0100, Arne Schwabe wrote:
We currently have a number of calls that fetch the cipher_kt from a
cipher_ctx to then do a query on the cipher_kt. Directly fetching the
desired property from the context is cleaner and helps for using the
proper APIs with OpenSSL 3.0 and mbed TLS 3.0
Generally speaking this seems reasonable, I just wonder about
two things:
@@ -68,12 +68,10 @@ openvpn_encrypt_aead(struct buffer *buf, struct buffer work,
int outlen = 0;
const struct key_ctx *ctx = &opt->key_ctx_bi.encrypt;
uint8_t *mac_out = NULL;
- const cipher_kt_t *cipher_kt = cipher_ctx_get_cipher_kt(ctx->cipher);
const int mac_len = OPENVPN_AEAD_TAG_LENGTH;
/* IV, packet-ID and implicit IV required for this mode. */
ASSERT(ctx->cipher);
- ASSERT(cipher_kt_mode_aead(cipher_kt));
ASSERT(packet_id_initialized(&opt->packet_id));
This ASSERT goes away now. It's there to ensure that "yeah, we're
really using an AEAD ciphere here" - which should, of course, never
trigger, but I assume Steffan had some reason to put it here.
Since we no longer use cipher_kt in that function at all, we also no
longer need to check it if it is AEAD. On the ctx we already check if
it is AEAD before calling this function:
if (cipher_ctx_mode_aead(opt->key_ctx_bi.encrypt.cipher))
{
openvpn_encrypt_aead(buf, work, opt);
}
It is basically a overly cautions "Is the cipher type really AEAD from a
AEAD context?"
@@ -371,7 +364,6 @@ openvpn_decrypt_aead(struct buffer *buf, struct buffer work,
ASSERT(frame);
ASSERT(buf->len > 0);
ASSERT(ctx->cipher);
- ASSERT(cipher_kt_mode_aead(cipher_kt));
Same thing here.
So - can we be "crypto level" secure that this is never needed?
Same here.
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
