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.
> @@ -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?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
