Re: Undefined reference with clang16 and address sanitizer
Here is the leak report ``` make[2]: Leaving directory '/home/nwatkins/src/redpanda-llvm16/vbuild/debug/clang/v_deps_build/nettle-prefix/src/nettle-build' echo stamp > eccdata.stamp ./eccdata curve25519 11 6 64 > ecc-curve25519.hT && mv ecc-curve25519.hT ecc-curve25519.h Table size: 256 entries = ==1667484==ERROR: LeakSanitizer: detected memory leaks Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x565361b74bfe in __interceptor_malloc /home/nwatkins/src/redpanda-llvm16/vbuild/llvm/src/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 #1 0x565361baf79e in gmp_default_alloc eccdata.c #2 0x565361bb7fbc in gmp_xalloc_limbs eccdata.c #3 0x565361bb8a1b in mpz_realloc eccdata.c #4 0x565361bb92ea in mpz_set (/home/nwatkins/src/redpanda-llvm16/vbuild/debug/clang/v_deps_build/nettle-prefix/src/nettle-build/eccdata+0x11c2ea) #5 0x565361bb96b5 in mpz_init_set (/home/nwatkins/src/redpanda-llvm16/vbuild/debug/clang/v_deps_build/nettle-prefix/src/nettle-build/eccdata+0x11c6b5) #6 0x565361bc377e in mpz_div_qr eccdata.c #7 0x565361bc426a in mpz_mod (/home/nwatkins/src/redpanda-llvm16/vbuild/debug/clang/v_deps_build/nettle-prefix/src/nettle-build/eccdata+0x12726a) #8 0x565361bf1412 in output_bignum_redc eccdata.c #9 0x565361be65b7 in output_curve eccdata.c #10 0x565361bde8e6 in main (/home/nwatkins/src/redpanda-llvm16/vbuild/debug/clang/v_deps_build/nettle-prefix/src/nettle-build/eccdata+0x1418e6) #11 0x7f965423bb49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #12 0x7f965423bc0a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #13 0x565361adb364 in _start (/home/nwatkins/src/redpanda-llvm16/vbuild/debug/clang/v_deps_build/nettle-prefix/src/nettle-build/eccdata+0x3e364) SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s). ``` On Sun, May 7, 2023 at 7:38 AM Niels Möller wrote: > > Noah Watkins writes: > > > (fwiw sanitizer does report a memory leak when eccdata is > > running at the end of make). > > If it looks like the sanitizer could be right, can you share the error > report? > > Regards, > /Niels > > -- > Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. > Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: ancient install-sh and texinfo.tex?
tor 2023-05-11 klockan 20:15 +0200 skrev Niels Möller: > Simon Josefsson writes: > > > How about this patch? They are not up to date and I couldn't find > > anywhere that uses them anyway. > > I agree texinfo.tex appears unused (nettle.texinfo is processed with > makeinfo and texi2pdf). If it is deleted, Makefile.in DISTFILES need > updating as well. > > I think install-sh is referenced by AC_PROG_INSTALL, which is used in > configure.ac, and it seems install-sh is mentioned in the generated > configure script. Ah, I just grep'ed in raw git repository, not bootstrapped. > Should I just copy latest version from > https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/install-sh > ? Yes, that is the latest version. > Probably a good idea to also update config.guess and config.sub to > latest versions (previous update in Nettle was a year ago). Indeed -- maybe put all of those updating commands in .bootstrap? Perhaps only run them on a --download parameter or similar. /Simon signature.asc Description: This is a digitally signed message part ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: ARCFOUR doc fixes
Simon Josefsson writes: > Hi > > What do you think? Looks good, thanks. Merged this, as well as your other doc fix. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: ancient install-sh and texinfo.tex?
Simon Josefsson writes: > How about this patch? They are not up to date and I couldn't find > anywhere that uses them anyway. I agree texinfo.tex appears unused (nettle.texinfo is processed with makeinfo and texi2pdf). If it is deleted, Makefile.in DISTFILES need updating as well. I think install-sh is referenced by AC_PROG_INSTALL, which is used in configure.ac, and it seems install-sh is mentioned in the generated configure script. Should I just copy latest version from https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/install-sh ? Probably a good idea to also update config.guess and config.sub to latest versions (previous update in Nettle was a year ago). Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: HPKE work continuation
Hi, I finally got back to this patch again. I made changes to the pull request. The changelog: - Got rid of the hpke_ctx structure and put everything as function parameters. I read your email then where you suggest to have a context for the symmetric part, which I think makes sense, but I want your input on the contextless version before making any changes. It may be easier to review at this stage. - All the non-BASE mode was removed - All the algorithms other than P256, SHA256 and AES128 were removed - The structures for the algorithms were put as public (in hpke.h) - I got an idea to get rid of the hpke_setup_* functions and leave the process to the user. The process is straightforward and leaves the API a lot cleaner. The contents of the setup functions can be used in the documentation as an example for setting up a sender/receiver. - Because of the change above the function hpke_encap, hpke_decap and hpke_key_schedule moved to the public header file. - The tests were adjusted too, but without much time invested in it Please take a look and let me know what do you think. Regards Norbert Pócs On Tue, Dec 13, 2022 at 4:48 PM Norbert Pocs wrote: > Sorry for the late reply, I got snowed in by work. > I will continue to work on this in the New year. > > We need an object responsible for the symmetric encryption/decryption, >> similar to the Context type in the spec. It's not clear to me if we >> need separate types for sender and receiver (as suggested in the spec) >> or if we can use the same type. >> > > iirc it does not have to be a separate type. > > As far as I see, it doesn't need to know what KDF or KEM was used when >> the context was created. >> > > No, the process is separated after the shared key. > > From the docs: >> >>: @deftypefun int hpke_seal (struct hpke_ctx @var{ctx}, uint8_t >> *@var{aad}, size_t @var{aad_len}, uint8_t *@var{pt}, size_t @var{pt_len}, >> uint8_t **@var{ct}, size_t *@var{ct_len}) >>: Encrypts a plaintext using an hpke context and an >>: optional additional authenticated data into ciphertext. >>: @end deftypefun >> >> I take it hpke_ctx argument should be a pointer, right? >> > > Yes it is, only a typo in the docs. > > >> Is it non-const because it needs to update the sequence number? >> > > Yes. > > >> The aad and pt arguments should be const, I think. pt_len will be known >> by the >> caller, but how can it query for the size of the corresponding cipher >> text? >> > > The ciphertext as well as the size of the ciphertext are output > arguments from the function. The variable is used to return the size > of the ciphertext. > > For other aead modes, nettle use a single length argument, and >> it's the lenght of the destination (ct for encrypto, pt for decrypt), >> > > I am adding it to the TODO list. > > * Then we need some way(s) way to create/initialize such a context, for >> sender and receiver. >> >> One way would be to have general function, which gets kdf, kem and >> aead to use as arguments. >> > > This is how it is done in the PR atm. > > Or would could take out some or all of that >> parameterization and have one function for each configuration. >> > > Would this approach bring anything valuable in difference to the first > approach? > > I'm afraid I don't know what is or isn't approved in FIPS 140-3. I think >> point validation might be simpler with curve25519 than with the secp >> curves. I'd prefer initial algorithm based on what you think is most >> useful for applications. >> > > curve25519 looks good to me, other algs can be HKDF-SHA256, AES-128-GCM. > > I think they should be public in that sense. However, there are some >> subtle details. Either they are completely public: You declare the types >> in the public hpke.h, and declare (as const extern struct ...) >> instances, details becomes part of the nettle ABI. This is like, e.g., >> const struct nettle_hash nettle_sha256. >> >> Or you only forward declare the type in hpke.h, like >> >> struct hpke_kem; >> >> which actual contents in the private hpke-internal.h. >> >> In that case, you cannot publicly declare constants (because in some >> caes that can result in copy relocations making the size of the struct >> leak into the abi, even though contents of the struct was intended to be >> private). Instead, you have to declare accessors, like >> >> const struct hpke_kem *hpke_get_curve25519(void); >> >> This is like struct ecc_curve is handled. >> > > I understand now. I will rework it to be "private" with accessors you are > describing above. > > Not sure what's the right way. But a context with lots of setter methods >> is rather different from most other things in Nettle. >> > > It will at least help with the rework of the context struct. > > >> I often find that it makes things clearer to have separation between the >> separate stages/layers, e.g.: First do algorithm parameterization, >> resulting in a struct representing an instantiation of hpke mode. Then
[PATCH] Add Streamlined NTRU Prime sntrup761.
Hi Please release 3.9 before looking at this! :-) This adds sntrup761, what do you think? Please consider it a first iteration for early review. The patch is on top off the previous drbg-ctr-aes256 patch, although I made a typo so you need to change 'drbg-ctr-aes256.c' into 'drbg-ctr-aes256-test.c' in testsuite/Makefile.in before applying that patch. I will use the following branches for further development: https://gitlab.com/jas/nettle/-/tree/jas/drbgr-ctr-aes256 https://gitlab.com/jas/nettle/-/tree/jas/sntrup761 /Simon From b04675909e19eaae9d46e5b912da15321e388d8d Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 11 May 2023 13:50:55 +0200 Subject: [PATCH] Add Streamlined NTRU Prime sntrup761. --- Makefile.in|4 +- nettle.texinfo | 49 ++ sntrup761.c| 1080 sntrup761.h| 75 +++ testsuite/.gitignore |1 + testsuite/Makefile.in |2 +- testsuite/sntrup761-test.c | 444 +++ 7 files changed, 1652 insertions(+), 3 deletions(-) create mode 100644 sntrup761.c create mode 100644 sntrup761.h create mode 100644 testsuite/sntrup761-test.c diff --git a/Makefile.in b/Makefile.in index 120cbc49..4a970116 100644 --- a/Makefile.in +++ b/Makefile.in @@ -165,7 +165,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c aes-decrypt-table.c \ write-be32.c write-le32.c write-le64.c \ yarrow256.c yarrow_key_event.c \ xts.c xts-aes128.c xts-aes256.c \ - drbg-ctr-aes256.c + drbg-ctr-aes256.c sntrup761.c hogweed_SOURCES = sexp.c sexp-format.c \ sexp-transport.c sexp-transport-format.c \ @@ -245,7 +245,7 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h blowfish.h balloon.h \ salsa20.h sexp.h serpent.h \ sha.h sha1.h sha2.h sha3.h sm3.h sm4.h streebog.h twofish.h \ umac.h yarrow.h xts.h poly1305.h nist-keywrap.h \ - drbg-ctr.h + drbg-ctr.h sntrup761.h INSTALL_HEADERS = $(HEADERS) version.h @IF_MINI_GMP@ mini-gmp.h diff --git a/nettle.texinfo b/nettle.texinfo index 2e4f56d3..f57cc37e 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -80,6 +80,7 @@ Reference * Keyed hash functions:: * Key derivation functions:: * Public-key algorithms:: +* Key-Encapsulation mechanisms:: * Randomness:: * ASCII encoding:: * Miscellaneous functions:: @@ -352,6 +353,7 @@ This chapter describes all the Nettle functions, grouped by family. * Keyed hash functions:: * Key derivation functions:: * Public-key algorithms:: +* Key-Encapsulation mechanisms:: * Randomness:: * ASCII encoding:: * Miscellaneous functions:: @@ -5967,6 +5969,53 @@ Verifies a message using the provided public key. Returns 1 if the signature is valid, otherwise 0. @end deftypefun +@node Key-Encapsulation mechanisms +@section Key-Encapsulation mechanisms + +@cindex Key-Encapsulation mechanisms +@cindex KEM + +Key-Encapsulation mechanisms allows a sender to take a public key as +input and produce (encapsulate) a session key wrapped in ciphertext, and +the receiver to extract (decapsulate) the session key using its private +key. + +Nettle supports the Streamlined NTRU Prime algorithm @code{sntrup761}. + +Nettle defines sntrup761 in @file{}. + +@defvr Constant SNTRUP761_SECRETKEY_SIZE +The size (1763 bytes) of the sntrup651 secret key. +@end defvr + +@defvr Constant SNTRUP761_PUBLICKEY_SIZE +The size (1158 bytes) of the sntrup651 secret key. +@end defvr + +@defvr Constant SNTRUP761_CIPHERTEXT_SIZE +The size (1039 bytes) of the sntrup651 ciphertext. +@end defvr + +@defvr Constant SNTRUP761_SIZE +The size (32 bytes) of the sntrup651 output key. +@end defvr + +@deftypefun void sntrup761_keypair (uint8_t *@var{pk}, uint8_t *@var{sk}, void *@var{random_ctx}, nettle_random_func *@var{random}); +Generate a sntrup761 public key @var{pk} and private key @var{sk}, using +randomness-generator @var{random} with context @var{random_ctx}. +@end deftypefun + +@deftypefun void sntrup761_enc (uint8_t *@var{c}, uint8_t *@var{k}, const uint8_t *@var{pk}, void *@var{random_ctx}, nettle_random_func *@var{random}); +Generate a session key @var{k} and encapsulate it into ciphertext +@var{c} for the recipient with public-key @var{pk}, using +randomness-generator @var{random} with context @var{random_ctx}. +@end deftypefun + +@deftypefun void sntrup761_dec (uint8_t *@var{k}, const uint8_t *@var{c}, const uint8_t *@var{sk}); +Decapsulate session key @var{k} from ciphertext @var{c} using the +private key @var{sk}. +@end deftypefun + @node Randomness @section Randomness diff --git a/sntrup761.c b/sntrup761.c new file mode 100644 index ..dc1ca015 --- /dev/null +++ b/sntrup761.c @@ -0,0 +1,1080 @@ +/* sntrup761.c + + Copyright (C) 2023 Simon Josefsson + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation;
[PATCH] Add DRBG-CTR-AES256.
Hi Please release 3.9 before looking at this! :-) This adds DRBG-CTR-AES256, what do you think? The DRBG-CTR specification is complex. I belive the non-essential functionality is actively harmful, and I spent time to reduce the complex algorithm into this minimal but still compliant version. Compare other implementations [1] [2] [3]. Unfortunately, finding test vectors has been harder than I thought, so please consider this a first iteration pending more test vectors of different output sizes. /Simon [1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=random/random-drbg.c;hb=HEAD [2] https://github.com/openssl/openssl/blob/master/providers/implementations/rands/drbg_ctr.c [3] https://github.com/torvalds/linux/blob/master/crypto/drbg.c From 2ebaf5b0e6e63b6c059daf37d147fdb1741a20da Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Wed, 10 May 2023 10:28:29 +0200 Subject: [PATCH] Add DRBG-CTR-AES256. --- Makefile.in | 6 +- NEWS | 6 ++ drbg-ctr-aes256.c| 100 +++ drbg-ctr.h | 69 + nettle.texinfo | 39 testsuite/.gitignore | 1 + testsuite/Makefile.in| 2 +- testsuite/drbg-ctr-aes256-test.c | 74 +++ 8 files changed, 294 insertions(+), 3 deletions(-) create mode 100644 drbg-ctr-aes256.c create mode 100644 drbg-ctr.h create mode 100644 testsuite/drbg-ctr-aes256-test.c diff --git a/Makefile.in b/Makefile.in index 2464e17e..120cbc49 100644 --- a/Makefile.in +++ b/Makefile.in @@ -164,7 +164,8 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c aes-decrypt-table.c \ version.c \ write-be32.c write-le32.c write-le64.c \ yarrow256.c yarrow_key_event.c \ - xts.c xts-aes128.c xts-aes256.c + xts.c xts-aes128.c xts-aes256.c \ + drbg-ctr-aes256.c hogweed_SOURCES = sexp.c sexp-format.c \ sexp-transport.c sexp-transport-format.c \ @@ -243,7 +244,8 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h blowfish.h balloon.h \ pgp.h pkcs1.h pss.h pss-mgf1.h realloc.h ripemd160.h rsa.h \ salsa20.h sexp.h serpent.h \ sha.h sha1.h sha2.h sha3.h sm3.h sm4.h streebog.h twofish.h \ - umac.h yarrow.h xts.h poly1305.h nist-keywrap.h + umac.h yarrow.h xts.h poly1305.h nist-keywrap.h \ + drbg-ctr.h INSTALL_HEADERS = $(HEADERS) version.h @IF_MINI_GMP@ mini-gmp.h diff --git a/NEWS b/NEWS index 333c181b..b21c6921 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,9 @@ +NEWS for the Nettle 3.10 release + + New features: + + * Added DRBG-CTR with AES256, contributed by Simon Josefsson. + NEWS for the Nettle 3.9 release This release includes bug fixes, several new features, a few diff --git a/drbg-ctr-aes256.c b/drbg-ctr-aes256.c new file mode 100644 index ..b3e8e194 --- /dev/null +++ b/drbg-ctr-aes256.c @@ -0,0 +1,100 @@ +/* drbg-ctr-aes256.c + + Copyright (C) 2023 Simon Josefsson + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +*/ + +#if HAVE_CONFIG_H +#include "config.h" +#endif + +#include "drbg-ctr.h" + +#include +#include "macros.h" +#include "memxor.h" + +static void +drbg_ctr_aes256_update (struct aes256_ctx *Key, + uint8_t *V, uint8_t *provided_data) +{ + uint8_t tmp[DRBG_CTR_AES256_SEED_SIZE]; + + INCREMENT (AES_BLOCK_SIZE, V); + aes256_encrypt (Key, AES_BLOCK_SIZE, tmp, V); + + INCREMENT (AES_BLOCK_SIZE, V); + aes256_encrypt (Key, AES_BLOCK_SIZE, tmp + AES_BLOCK_SIZE, V); + + INCREMENT (AES_BLOCK_SIZE, V); + aes256_encrypt (Key, AES_BLOCK_SIZE, tmp + 2 * AES_BLOCK_SIZE, V); + + if (provided_data) +memxor (tmp, provided_data, 48); + + aes256_set_encrypt_key (Key, tmp); + + memcpy (V, tmp + AES256_KEY_SIZE, AES_BLOCK_SIZE); +} + +void +drbg_ctr_aes256_init (struct drbg_ctr_aes256_ctx *ctx, uint8_t *seed_material) +{ + uint8_t Key[AES256_KEY_SIZE]; + + memset (Key, 0, AES256_KEY_SIZE); + aes256_set_encrypt_key (&ctx->Key, Key); + + memset (ctx->V, 0, AES_BLOCK_SIZE); + + drbg_ctr_aes256_upda
[PATCH] Doc fix for version and date.
From 64f42624c8a40d43b612f41d4bfe7eee06898331 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 11 May 2023 12:18:11 +0200 Subject: [PATCH] Doc fix for version and date. --- nettle.texinfo | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/nettle.texinfo b/nettle.texinfo index a73f1635..1c807f70 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -8,14 +8,14 @@ @syncodeindex tp cp @c %**end of header -@set UPDATED-FOR 3.4 +@set UPDATED-FOR 3.9 @set AUTHOR Niels Möller @copying This manual is for the Nettle library (version @value{UPDATED-FOR}), a low-level cryptographic library. -Originally written 2001 by @value{AUTHOR}, updated 2017. +Originally written 2001 by @value{AUTHOR}, updated 2023. @quotation This manual is placed in the public domain. You may freely copy it, in -- 2.34.1 signature.asc Description: PGP signature ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
ARCFOUR doc fixes
Hi What do you think? /Simon From 63cdb2a5ca75392c982315f84143d7e32c340588 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 11 May 2023 12:03:21 +0200 Subject: [PATCH] Document more ARCFOUR issues. --- nettle.texinfo | 38 -- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/nettle.texinfo b/nettle.texinfo index a73f1635..18d7d1e7 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -1418,15 +1418,23 @@ Analogous to the encryption functions above. @cindex Arcfour @cindex RC4 -ARCFOUR is a stream cipher, also known under the trade marked name RC4, -and it is one of the fastest ciphers around. A problem is that the key -setup of ARCFOUR is quite weak, you should never use keys with -structure, keys that are ordinary passwords, or sequences of keys like -``secret:1'', ``secret:2'', @enddots{}. If you have keys that don't look -like random bit strings, and you want to use ARCFOUR, always hash the -key before feeding it to ARCFOUR. Furthermore, the initial bytes of the -generated key stream leak information about the key; for this reason, it -is recommended to discard the first 512 bytes of the key stream. +ARCFOUR is a historic stream cipher, also known under the trade marked +name RC4, and was a widely used fast stream cipher. + +We do not recommend the use of ARCFOUR; the Nettle implementation is +provided primarily for interoperability with existing applications and +standards. + +One problem is that the key setup of ARCFOUR is quite weak, you should +never use keys with structure, keys that are ordinary passwords, or +sequences of keys like ``secret:1'', ``secret:2'', @enddots{}. If you +have keys that don't look like random bit strings, and you want to use +ARCFOUR, always hash the key before feeding it to ARCFOUR. + +Another problem is that the output is distinguishable from random data, +and that the initial bytes of the generated key stream leak information +about the key; for this reason, it was sometimes recommended to discard +the first 512, 768 or 1024 bytes of the key stream. @example /* A more robust key setup function for ARCFOUR */ @@ -6142,11 +6150,13 @@ what output is generated after @code{t_2}. Nettle includes one randomness generator that is believed to have all the above properties, and two simpler ones. -@acronym{ARCFOUR}, like any stream cipher, can be used as a randomness -generator. Its output should be of reasonable quality, if the seed is -hashed properly before it is used with @code{arcfour_set_key}. There's -no single natural way to reseed it, but if you need reseeding, you -should be using Yarrow instead. +@acronym{ChaCha} (@pxref{ChaCha}), like any stream cipher, can be used +as a randomness generator. Its output should be of reasonable +quality. There's no single natural way to reseed it, but if you need +reseeding, you should be using Yarrow instead. Historically ARCFOUR +(@pxref{Arcfour}) has been used as a randomness generator, however it is +known to be distinguishable from random data and the output leaks +information about the key. The ``lagged Fibonacci'' generator in @file{} is a fast generator with good statistical properties, but is @strong{not} for -- 2.34.1 signature.asc Description: PGP signature ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se