Page MenuHomeFreeBSD

ossl: Don't try to initialize the cipher for Chacha20+Poly1305.
ClosedPublic

Authored by jhb on Jun 16 2023, 5:36 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sep 24 2024, 9:33 AM
Unknown Object (File)
Sep 23 2024, 6:08 PM
Unknown Object (File)
Sep 16 2024, 6:57 PM
Unknown Object (File)
Sep 16 2024, 2:44 AM
Unknown Object (File)
Sep 15 2024, 8:36 PM
Unknown Object (File)
Sep 15 2024, 4:31 AM
Unknown Object (File)
Sep 5 2024, 3:51 AM
Unknown Object (File)
Aug 8 2024, 7:32 AM
Subscribers

Details

Summary

Chacha20+Poly1305 doesn't use an ossl_cipher instance the way AES-GCM
does, so ossl_lookup_cipher() failed causing ossl_newsession() to
always fail for Chacha20+Poly1305 sessions.

Reported by: gallatin (ktls_test fails with ossl.ko loaded)
Fixes: 9a3444d91c70 ossl: Add a VAES-based AES-GCM implementation for amd64
Tested by: gallatin

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Jun 16 2023, 5:36 PM

This allows the ktls tests for chacha poly to pass when the ossl driver is attached.

Is anything verifying csp_cipher_klen when probing/creating a CRYPTO_CHACHA20_POLY1305 session in ossl(4)?

Is anything verifying csp_cipher_klen when probing/creating a CRYPTO_CHACHA20_POLY1305 session in ossl(4)?

There is only one valid key length, and this is checked in csp_sanity in crypto.c. In general I've tried to consolidate checks that are always-false for a given algorithm in crypto.c to avoid duplicating them in drivers. Instead, drivers only need to check when there is a range of a parameters for which a driver might only permit a subset of the (e.g. if only a subset of AES key lengths are supported).

However, it is true that the other way to fix this perhaps is to add an ossl_cipher instance for Chacha20+Poly1305. (Key length checks would also be in probesession and not in newsession FWIW)

In D40580#923960, @jhb wrote:

Is anything verifying csp_cipher_klen when probing/creating a CRYPTO_CHACHA20_POLY1305 session in ossl(4)?

There is only one valid key length, and this is checked in csp_sanity in crypto.c.

Do you mean check_csp()? I can't see how it verifies that the key length is equal to 32. (And even if it did, it doesn't do that for per-request keys.)

In general I've tried to consolidate checks that are always-false for a given algorithm in crypto.c to avoid duplicating them in drivers. Instead, drivers only need to check when there is a range of a parameters for which a driver might only permit a subset of the (e.g. if only a subset of AES key lengths are supported).

In D40580#923960, @jhb wrote:

Is anything verifying csp_cipher_klen when probing/creating a CRYPTO_CHACHA20_POLY1305 session in ossl(4)?

There is only one valid key length, and this is checked in csp_sanity in crypto.c.

Do you mean check_csp()? I can't see how it verifies that the key length is equal to 32. (And even if it did, it doesn't do that for per-request keys.)

Humm, I thought I had pulled most of these checks into check_csp(). They belong there (and that's where I'd rather add it). Per-request keys don't use a separate key length per request, they reuse csp_cipher_klen, so checking csp_cipher_klen in check_csp() should be sufficient for both session and per-request key lengths.

In general I've tried to consolidate checks that are always-false for a given algorithm in crypto.c to avoid duplicating them in drivers. Instead, drivers only need to check when there is a range of a parameters for which a driver might only permit a subset of the (e.g. if only a subset of AES key lengths are supported).

This revision is now accepted and ready to land.Jun 19 2023, 7:11 PM