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.
[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
[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 (>Key, Key);
+
+ memset (ctx->V, 0, AES_BLOCK_SIZE);
+
+ drbg_ctr_aes256_update
[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
