| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
xchacha is a chacha stream that allows for an extended nonce, which
in turn makes it feasible to use random nonces.
ok tb@
|
| |
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
|
|
| |
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@
|
| | |
|
| |
|
|
| |
ok beck@
|
| |
|
|
| |
ok beck@ jsing@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| | |
|
| | |
|
| |
|
|
| |
from Brent Cook
|
| | |
|
| | |
|
| |
|
|
| |
ok miod@
|
|
|
ok deraadt@
|
