Daiki Ueno authored Mar 09, 2020 and Niels Möller committed Mar 09, 2020

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>

Daiki Ueno authored Mar 09, 2020 and Niels Möller committed Mar 09, 2020

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>

Nikos Mavrogiannopoulos authored Jun 06, 2018 and Niels Möller committed Jul 07, 2018

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.