openbsd/src/lib/libcrypto/chacha, branch libressl-v3.8.0A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=libressl-v3.8.02022-08-20T18:44:58+00:00Remove UINT32_MAX limitation on ChaCha() and CRYPTO_chacha_20().2022-08-20T18:44:58+00:00jsing2022-08-20T18:44:58+00:00urn:sha1:c4f5cc12854a0a64258f9452a1d89656f20a1ca8
We can avoid this unnecessary limitation by calling chacha_encrypt_bytes()
multiple times internally. In the case of ChaCha(), the caller still needs
to ensure that the same IV is not used for more than 2^70 bytes.
ok tb@
Switch from u_int and u_char to u32 and u8 to avoid portability issues.2021-10-22T17:43:00+00:00tb2021-10-22T17:43:00+00:00urn:sha1:f88a73e4ec84a81466950e92df5ae0ecab269bde
Prompted by a diff by Jonas Termansen.
ok jsing
add support for xchacha20 and xchacha20-poly13052019-01-22T00:59:21+00:00dlg2019-01-22T00:59:21+00:00urn:sha1:4dfb993f9f695f40d03730129e2c082223711b65
xchacha is a chacha stream that allows for an extended nonce, which
in turn makes it feasible to use random nonces.
ok tb@
Convert the sigma and tau initialisers to byte arrays, rather than using2017-08-13T16:55:31+00:00jsing2017-08-13T16:55:31+00:00urn:sha1:ae4d6b8586e285ed1d7d18a7a183f18f35fc8b1c
strings. The original code is perfectly valid C, however it causes some
compilers to complain since it lacks room for a string NUL terminator and
the compiler is not smart enough to realise that these are only used as
byte arrays and never treated as strings.
ok bcook@ beck@ inoguchi@
Change the counter argument for CRYPTO_chacha_20 to be 64-bits on all platforms.2015-12-09T14:07:55+00:00bcook2015-12-09T14:07:55+00:00urn:sha1:9c3c66be91c8f6aee01b5b594cb0340b86a35bfb
The recently-added EVP_aead_chacha20_poly1305_ietf() function, which implements
informational RFC 7539, "ChaCha20 and Poly1305 for IETF Protocols", needs a
64-bit counter to avoid truncation on 32-bit platforms.
The existing TLS ChaCha20-Poly1305 ciphersuite is not impacted by this, but
making this change requires an ABI bump.
ok jsing@, "Looks sane" beck@
Add missing year to copyright.2014-07-25T14:04:51+00:00jsing2014-07-25T14:04:51+00:00urn:sha1:155fbc115e08fe35c3363e1eec376f81c141a5f7replace u_int8_t with uint8_t2014-07-11T08:47:47+00:00bcook2014-07-11T08:47:47+00:00urn:sha1:2ca0a041179d92f856da4e6fbfa2b4d62c44be06
ok beck@
add missing stdint. include for uint32_t, etc.2014-07-08T14:30:23+00:00bcook2014-07-08T14:30:23+00:00urn:sha1:4e034cc02822d664dec3b2e45e8e620fd3301ed3
ok beck@ jsing@
If a chacha operation does not consume all of the generated key stream,2014-06-24T18:12:09+00:00jsing2014-06-24T18:12:09+00:00urn:sha1:125ab32227935a33d4c3ef80e58ed8f9d7cfbe8d
ensure that we save it and consume it on subsequent writes. Otherwise we
end up discarding part of the key stream and instead generate a new block
at the start of the next write.
This was only an issue for callers that did multiple writes that are not
multiples of 64 bytes - in particular, the ChaCha20Poly1305 usage does not
hit this problem since it performs encryption in a single-shot. For the
same reason, this is also a non-issue when openssl(1) is used to encrypt
with ChaCha.
Issue identified by insane coder; reported to bugs@ by Joseph M. Schwartz.
ok beck@
Some KNF.2014-06-24T17:48:30+00:00jsing2014-06-24T17:48:30+00:00urn:sha1:c58a8845c63797e02604d37d10de2de9a1f8b046