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

[jhb]

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

[gallatin]

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

[markj]

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

[jhb]

In D40580#923935, @markj 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. 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).

[jhb]

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)

[markj]

In D40580#923960, @jhb wrote:

In D40580#923935, @markj 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).

[jhb]

In D40580#924448, @markj wrote:

In D40580#923960, @jhb wrote:

In D40580#923935, @markj 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).