CHACHA20 POLY1305 succeeds with IV size of 16 (OpenSSL CVE-2019-1543)

[guidovranken]

OpenSSL addressed this: https://www.openssl.org/news/secadv/20190306.txt

I've been working around this in my fuzzer (https://github.com/guidovranken/cryptofuzz/blob/5a41fd9293b818a8094ca9c9a0b491f9eb5e2b76/modules/mbedtls/module.cpp#L390-L395) but maybe this is something you'd like to address?

[chris-jones-arm]

Thanks for the report @guidovranken, we will try to schedule this work in soon.

Note: Having checked this in the code I can verify that the nonce is documented to only be 96 bits however it is never checked by the library.

[gilles-peskine-arm]

This affects CHACHA20 as well. The cipher module takes an iv_len parameter but does not validate it. The low-level modules (chacha20.c and chachapoly.c) both expect a fixed IV length and don't take a length parameter.

This is only a problem in the classic cipher interface. The PSA code calls cipher for CHACHA20 and has its own nonce validation for CHACAHA20_POLY1305.

[gilles-peskine-arm]

This issue affects modes with a fixed IV size (all except GCM and CCM), and only if the fixed size is neither 0 nor MBEDTLS_MAX_IV_LENGTH (which is 16). As a consequence, the only affected modes are ChaCha20 and Chacha20-Poly1305.

[AndrzejKurek]

The cipher behavior fix is trivial, but the way we handle iv in our tests is a problem.
We use the same size of iv (16) for our enc/dec tests using test_suite_cipher.function, and I don't see a trivial way to fix it apart from the cumbersome way of adding an iv_len parameter to all of the tests and make an exception to use 12 for ChaCha20 and ChaCha20-Poly1305.
Do you have anything better in mind, @gilles-peskine-arm?

[gilles-peskine-arm]

@AndrzejKurek For the functions that have a hard-coded IV, I think making the IV length a function of the cipher ID is a reasonable solution.

For negative tests, I guess we have to add a new function anyway?