wireguard-openbsd/lib/libcrypto/chacha, branch jd/simplify-queueing WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/lib/libcrypto/chacha?h=jd%2Fsimplify-queueing 2019-01-22T00:59:21Z add support for xchacha20 and xchacha20-poly1305 2019-01-22T00:59:21Z dlg dlg@openbsd.org 2019-01-22T00:59:21Z urn:sha1:64bf23976d44f1dec50f86a3ac43a0945d6605be 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 using 2017-08-13T16:55:31Z jsing jsing@openbsd.org 2017-08-13T16:55:31Z urn:sha1:2890ee3ddf02abfb7bb52c9cb911ca24a73a6547 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:55Z bcook bcook@openbsd.org 2015-12-09T14:07:55Z urn:sha1:fac5bb4f638242227893433c019a8841edcb8207 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:51Z jsing jsing@openbsd.org 2014-07-25T14:04:51Z urn:sha1:7a13518141d2d9e57ae189ed5bb7485eb7513bbd replace u_int8_t with uint8_t 2014-07-11T08:47:47Z bcook bcook@openbsd.org 2014-07-11T08:47:47Z urn:sha1:bef316a166d8a261bfd3a32e3682b5a4719adac7 ok beck@ add missing stdint. include for uint32_t, etc. 2014-07-08T14:30:23Z bcook bcook@openbsd.org 2014-07-08T14:30:23Z urn:sha1:e693045f0effea3e02a4d042a5c4e91562cedb53 ok beck@ jsing@ If a chacha operation does not consume all of the generated key stream, 2014-06-24T18:12:09Z jsing jsing@openbsd.org 2014-06-24T18:12:09Z urn:sha1:61bfdc17bc6088c6118a56366ced983452cbf3d1 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:30Z jsing jsing@openbsd.org 2014-06-24T17:48:30Z urn:sha1:21f5cfdbca663587bbc30d7596ffc2f8e8731f44 tags as requested by miod and tedu 2014-06-12T15:49:27Z deraadt deraadt@openbsd.org 2014-06-12T15:49:27Z urn:sha1:c3d6a26af7455bccce87985ff78ef0efc39b65e1 Get the public headers from the official place with <openssl/ > 2014-05-31T23:33:32Z deraadt deraadt@openbsd.org 2014-05-31T23:33:32Z urn:sha1:6d6bb18994334260a699979d2d2e50b33951a156 from Brent Cook