| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The ChaCha-Poly1305 implementation previously used the chacha_crypt
function that assumes the block counter is 64-bit long, while RFC 8439
defines that the counter is 32-bit long. Although this should be fine
as long as up to 256 gigabytes of data is encrypted with the same key,
it would be nice to use a separate functions (chacha_set_counter32 and
chacha_crypt32) that assume the counter is 32-bit long.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The ChaCha20 based header protection algorithm in QUIC requires a way
to set the initial value of counter:
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based-header-prote
This will add a new function chacha_set_counter, which takes an
8-octet initial value of the block counter.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds all exported symbols in the map files explicitly under
the following rules:
- Symbols mentioned in internal headers go in a section which is
valid only for testing, and linking with these symbols will break
in library updates.
- Symbols mentioned in installed headers go in the exported sections
and are considered part of the ABI.
- All internal symbols move to internal headers.
- The _nettle_md5_compress and _nettle_sha1_compress become exported
without the _nettle prefix, due to existing usage.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
