CHACHA20 POLY1305 succeeds with IV size of 16 (OpenSSL CVE-2019-1543)
guidovranken opened this issue · comments
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?
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.
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.
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.
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?
@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?