Re: [PATCH] Add DRBG-CTR-AES256.

[Simon Josefsson]

Niels Möller  writes:

> Simon Josefsson  writes:
>
>> Fortuna is newer but I wonder if anyone will ever use Nettle to
>> implement this functionality?  Maybe the Nettle documentation could
>> suggest that anyone considering Yarrow should research alternatives
>> first.
>
> Do you know what GnuTLS uses for randomness? LSH (my SSH implementation)
> uses Nettle's yarrow, but I guess that's rather obscure now.

GnuTLS these days has its own RNG stack which is more complex than what
Nettle provides natively.

https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/rnd.c
https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/sysrng-linux.c

>> DRBG-CTR is strange in several ways (e.g., non-uniform seeds), to the
>> point of being unsafe since it is easy to misuse it.
>
> Is that detailed in the paper you link to?

The details and assumptions are clear from the NIST spec, but the
subjective opinion that it is easy to mis-use is my own.

>> Considering Dual-EC-DRBG, perhaps standardizing "problematic" prng's
>> was a design goal with 800-90A, and in that case the DRBG-CTR designs
>> makes a whole lot more sense and would be an appropriate algorithm.
>>
>> Maybe it should only be added as internal functionality to Nettle...
>
> It could be documented with caveats (usage for anything but tests
> discouraged, with some brief motivation and/or pointers to references on
> how it's bad), motivated by applications that need to comply with that
> standard. Or mentioned but undocumented in a similar way as the
> knuth_lfib generator. Or kept completely internal.
>
> Since the interface (of the subset you support) is rather simple, and
> according to Joachim there are some use cases, I'd lean towards
> documenting it.

My initial patch contained documentation.  While it can always be
expanded a lot more, I can't think of any further modifications.

/Simon


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

Re: CI cross builds failing, advice needed

[Simon Josefsson]

Niels Möller  writes:

> 1. Switch to the cross-fedora38 image
>
> (https://gitlab.com/gnutls/build-images/-/blob/master/docker-cross-fedora38/Dockerfile?ref_type=heads).
>
> 2. Use some official debian image (not maintained by gnutls), and
>install needed cross compilers as part of each job.
>
> 3. Maintain a separate image (or images) for use by Nettle ci builds.
>E.g., I'm considering adding more tests depending on valgrind, so
>then it would be nice to include valgrind in the image. And it would
>be nice if all apt commands in the ci scripts could be eliminated.

I think that it would be better for nettle to maintain separate
build-images and not rely on other project's build-images.  We could add
'gnutls/nettle-build-images' for this if you want?  Or is there some
other more canonical home for nettle on gitlab already?

> Efficiency could matter: extra work, like installing lots of packages as
> part of each ci job, makes the ci more expensive, and I don't know what
> limits there are to the gnutls project on gitlab, but by default. So
> advice appreciated.

Compared to gnutls pipeline, I don't think the nettle pipeline will be
significant in the resource consumption.  The build/gnutls job takes a
while, and maybe it could be speed up somehow.

My experience is that it can help to have some build image for stable
released well-known OSs but not create one for every single variant.
However looking at build times most of the jobs are 1-3 minutes which is
quite quick already.  I usually don't bother until the jobs start to
take more than 5 minutes to complete.

/Simon

> PS. On the topic on valgrind: Is it possible/practical to use valgrind
> in a cross setting, e.g., an x86_64 host, cross compiling for arm, and
> then use qemu-arm to run an arm valgrind binary in turn running the arm
> binary under test. Or is there some other way to run a cross valgrind?

What do you want to achieve?  If valgrind on arm is the goal, rather
than testing the cross-build setup, it may be simpler to have a macOS
build job with valgrind.

/Simon


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

Re: [PATCH] Add DRBG-CTR-AES256.

[Simon Josefsson]

Niels Möller  writes:

> Simon Josefsson  writes:
>
>> This adds DRBG-CTR-AES256, what do you think?
>
> Thanks, I've had a first look.

Thanks for review!

>> +  INCREMENT (AES_BLOCK_SIZE, V);
>> +  aes256_encrypt (Key, AES_BLOCK_SIZE, tmp + 2 * AES_BLOCK_SIZE, V);
>
> You could perhaps use ctr_fill16 or something similar for this,
> currently a static function in ctr.c. Even though I guess it's
> appropriate to aim for clarity rather than highest performance for this
> function.
>
> Hmm, or fill tmp with zeros, followed by a call to _nettle_ctr_crypt16
> (implies a redundant memxor operation, but perhaps simpler code)?

I started looking at ctr* too, but ended up doing more and more changes
to ctr*c than I felt comfortable with since I don't understand those
functions well enough.  One issue is that DRBG-CTR increments before
AES, and normal CTR has the reverse order.

>> +We support what we believe is the reasonable parts of the CTR_DRBG
>> +algorithm for AES256.  Re-seeding, personalization strings, derivation
>> +functions and support for non-AES256 is not implemented.
>> +Personalization strings can be implemented by the caller, if desired,
>> +with xor.  If you need re-seeding or entropy derivation, we suggest that
>> +you use Yarrow instead.
>
> Side question: Is Yarrow still a reasonable recommendation, or would it
> be good to add some alternative (either its successor Fortuna, or
> something completely different)?

Fortuna is newer but I wonder if anyone will ever use Nettle to
implement this functionality?  Maybe the Nettle documentation could
suggest that anyone considering Yarrow should research alternatives
first.

>> +Our suggested use-case for DRBG-CTR is to deterministically generate
>> +known values from a seed when comparing against expected values for some
>> +other algorithm.
>
> That's a rather limited usecase. Do you think it's inappropriate to use,
> e.g., to expand a short secret seed into multiple subkeys?

I would use HKDF for that.

DRBG-CTR is strange in several ways (e.g., non-uniform seeds), to the
point of being unsafe since it is easy to misuse it.  Considering
Dual-EC-DRBG, perhaps standardizing "problematic" prng's was a design
goal with 800-90A, and in that case the DRBG-CTR designs makes a whole
lot more sense and would be an appropriate algorithm.

Maybe it should only be added as internal functionality to Nettle...

/Simon


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

Re: [PATCH] Add Streamlined NTRU Prime sntrup761.

[Simon Josefsson]

Niels Möller  writes:

> Simon Josefsson  writes:
>
>> No objection, but I find it challenging to come up with a revised patch
>> that I feel comfortable with in the near future.  I'm not sure I even
>> understood what unused functions you noticed (and how?); that fix would
>> be easy to do.  Gaining confidence in rewritten parts feels a bit more
>> complicated.  Would you like to revise the code?
>
> I may be able to try it out in the next few weeks. If I just check out
> your branch, do tests work out of the box or do I need to somehow patch
> in the DRBG-CTR-AES256 too?

Yes self-tests should work, and drbg-ctr is included.

DRBG-CTR is only needed for sntrup761 self-testing, to reproduce some
published test vectors.  It would be nice to have test vectors that is
not based on DRBG-CTR, but I don't know of any.

Btw, I suspect that if too much of the implementation changes (in
particular, the randomness call ordering), the current test vectors will
fail.  I may be wrong, and I don't know how other crypto libraries deal
with this concern; maybe better approaches are known.

> There are some style details in the current patch that bothers me a bit,
> e.g., "q" used as a regular parameter/variable in most of the code, and
> then defined as a macro further down.
>
>   #define q 4591
>
> should be changed to something like
>
>   #define SNTRUP761_Q 4591
>
> (or maybe just SNTRUP_Q if it is intended to parametrize the code). 

+1

>> Aligned API/ABI's are nice, and good to get right early.  Is
>> 'nettle_block16' still the right way to do this, or is this possible to
>> (with arguably more readable) aligned() or alignof() attributes?
>
> I think nettle_block16 is the way to go, for representing 16 byte blocks
> where we're in control of the alignment (in contrast, e.g, to user's
> plaintext/cryptotext for which we don't require any alignment).
>
> I'd like to use alignas, and make nettle_block16 16-byte aligned at
> least on x86_64 (and on other archs where assembly code can benefit from
> alignment larger than that of an uint64). But aligned is C11, and I
> hesitate to require that (while I'm considering requiring C99). And
> since this is in public header files and part of the abi, it doesn't
> make sense with compiler specific ifdefs.

Thanks for explaining.  Your rationale for what variables are
appropriate for aligning, and which are not, makes sense and may be
useful to document.

/Simon


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

Re: [PATCH] Add Streamlined NTRU Prime sntrup761.

[Simon Josefsson]

Niels Möller  writes:

>>> My take was that it would be nice to add sntrup761 to Nettle ASAP to
>>> stabilize API and establish support for the algorithm -- we can optimize
>>> or improve the implementation later on (there are many optimized
>>> implementations around for different architectures out there).
>>
>> Makes sense, if it's clear what api and abi should look like (but, e.g.,
>> use of union nettle_block16 does affect the abi, I think).
>
> Having a closer look at the header file defining the api. I see no abi
> subtleties here, only naming nits.
>
>   * sntrup761_keypair: should be sntrup761_generate_keypair, for consistency.

+1

>   * sntrup761_enc, sntrup761_dec: Maybe abbreviate less, is
> _encapsulate and _decapsulate too much? Or is _enc and _dec really
> established in the area?

I think _enc and _dec are easy to confuse with _encrypt and _decrypt,
which would be unfortunate.

I like _encapsulate and _decapsulate.

>   * SNTRUP761_PUBLICKEY_SIZE: I think it would be more consistent with
> an underscore, _PUBLIC_KEY_SIZE.

+1

>   * SNTRUP761_SECRETKEY_SIZE: I prefer SNTRUP761_PRIVATE_KEY_SIZE is
> more consistent (maybe "private key" is not modern, but it's the
> terminology used for all other asymmetric algorithms in nettle).

+1

>   * SNTRUP761_CIPHERTEXT_SIZE: Probably right, even though I'm a bit
> confused by the "ciphertext" terminology when there's no
> corresponding plaintext.

Yeah... I think this is actually an area that could do more work, since
the output is combined but maybe some consumers could want to split it
up.  This could be fixed later, and there may be good reasons to NOT
expose that internal structure.  The terminology is a bit unclear if the
key is included in ciphertext or not.

>   * SNTRUP761_SIZE: This needs a more specific name, maybe _SECRET_SIZE,
> _SHARED_SECRET_SIZE, _SESSION_KEY_SIZE, _OUTPUT_SIZE, ...?

I think the acronym 'ss' is widely used for PQC KEM output secrets, so
+1 for SNTRUP761_SHARED_SECRET_SIZE.

The term 'session' confuses KEM's with D-H key agreement, and I think
these are somewhat different animals to warrant different terminology.

> In your docs, I noticed a copy-paste error in the docs for
> SNTRUP761_PUBLICKEY_SIZE.

\o/

> Things I think are desirable to do before merging an initial version:
> Agree on naming. Rename the single-lower-case-letter macros in the .c
> file to macro-like names. Add valgrind-based tests of side-channel silence.

Agreed, let's get those fixed.

/Simon


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

Re: [PATCH] Add Streamlined NTRU Prime sntrup761.

[Simon Josefsson]

Niels Möller  writes:

> Simon Josefsson  writes:
>
>>> In general, it makes sense to add support for post-quantum key exchange
>>> methods, another candidate seems to be https://classic.mceliece.org/
>>> (with the drawback of much larger pubkeys).
>>
>> +1
>
> I've been asking some other people too. sntrup seems to be a good option.
> Classic mcelice makes sense too, with a different underlying problem,
> and a different tradeoff (possible more conservative security, but
> larger pubkeys). Other NIST candidates Saber and Kyber I'm told have
> some patent issues, so I prefer not to touch them until that has been
> sorted out.

Sounds good, and the same for non-streamlined NTRU Prime.

> So should we focus on getting sntrup761 in as the first post-quantum
> key exchange algorithm?

+1

>> Also, do we want to deviate from audited implementations?
>
> Good question. I think the answer is yes. Some considerations:
>
> * We need proper tests for changes, including side-channel things that
>   can be tested with valgrind.
>  
> * If I have to choose between audited code and readable code, I think I
>   would usually go for the latter.
>
> * It's nice to have code consistent with general style in Nettle. And
>   more importantly, run-time selection of code should be done with the
>   same fat machinery as for other algorithms.
>
> * To me, it seems unlikely that we could wrap the audited reference
>   implementation in a way that is both practical, and makes the audit
>   provide significant confidence in the complete Nettle implementation.

No objection, but I find it challenging to come up with a revised patch
that I feel comfortable with in the near future.  I'm not sure I even
understood what unused functions you noticed (and how?); that fix would
be easy to do.  Gaining confidence in rewritten parts feels a bit more
complicated.  Would you like to revise the code?  Maybe we can all
review on the list.

>> My take was that it would be nice to add sntrup761 to Nettle ASAP to
>> stabilize API and establish support for the algorithm -- we can optimize
>> or improve the implementation later on (there are many optimized
>> implementations around for different architectures out there).
>
> Makes sense, if it's clear what api and abi should look like (but, e.g.,
> use of union nettle_block16 does affect the abi, I think).

Aligned API/ABI's are nice, and good to get right early.  Is
'nettle_block16' still the right way to do this, or is this possible to
(with arguably more readable) aligned() or alignof() attributes?

/Simon


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

Re: [PATCH] Add Streamlined NTRU Prime sntrup761.

[Simon Josefsson]

Thanks for reviewing this!

Niels Möller  writes:

> Simon Josefsson  writes:
>
>> This adds sntrup761, what do you think?
>
> What's the context/usecase? I saw some mails on the ietf-ssh list, but
> it was a bit unclear to me what the status of this algorithm is.

Sntrup761 is used by default in OpenSSH (hybrid with X25519) since some
years ago, and they are committed to support it for a many more years.
The ietf-ssh posts were about documenting that protocol.

My context for wanting it in Nettle is to reduce code duplication for
other projects that will end up implementing it too.  Unfortunately I
think we'll need to add native sntrup761 code to some other projects
anyway, until Nettle with sntrup761 is widely available.

> In general, it makes sense to add support for post-quantum key exchange
> methods, another candidate seems to be https://classic.mceliece.org/
> (with the drawback of much larger pubkeys).

+1

>> Please consider it a first iteration for early review.
>
> I initially looked at the arithmetics. The signed (int32) sorting and
> division seems unused?

Do you mean crypto_sort_int32?  It is called by crypto_sort_uint32.

> For the side-channel silent divmod function, it seems we divide
> exclusively with one or a few constants, then we could precompute
> needed constants and perhaps simplify a bit.

Possibly - this is reference code and supports other sntrup lengths.
Supporting multiple lengths often leads to complexity which leads to
reduced security.  As far as I can tell, the non-sntrup761 lengths were
insisted upon by NIST.  So the answer depends on if we want to allow
this code to be re-used by other sntrup lengths too.  Also, do we want
to deviate from audited implementations?

My take was that it would be nice to add sntrup761 to Nettle ASAP to
stabilize API and establish support for the algorithm -- we can optimize
or improve the implementation later on (there are many optimized
implementations around for different architectures out there).  The
patch I posted is similar to the reference code that is also used by
OpenSSH.

/Simon


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

Re: ancient install-sh and texinfo.tex?

[Simon Josefsson]

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

[PATCH] Add Streamlined NTRU Prime sntrup761.

[Simon Josefsson]

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.

[Simon Josefsson]

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

[PATCH] Doc fix for version and date.

[Simon Josefsson]

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

[Simon Josefsson]

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

Re: Ed25519 verify details

[Simon Josefsson]

"Niels Möller"  writes:

> Hi,
>
> A few weeks ago, I stumbled on
> https://hdevalence.ca/blog/2020-10-04-its-25519am. Summary: The
> specification for Ed25519 signatures, RFC 8032, doesn't specify
> unambiguously which bit strings are valid signatures, and which aren't.
> And implementations differ on the details.
>
> This could matter in particular if you have a system that depends on
> consensus, one could then feed the system a signed data item, where
> different components of the system disagree on whether or not the
> signature is valid.
>
> It's not clear to me what's the desired behavior for Nettle's
> ed25519_sha512_verify function, advice appreciated. A first step would
> be to add tests with the different kinds of corner-case inputs that may
> or may not be recognized as valid signatures, and at least document how
> they are handled.

This is a bit of a mess, unfortunately, and one solution may be to
implement a non-solution approach: instead of changing the sign or
verify operations, a new operation that can test the signature for
conformance to each of the useful behaviours could be added.  Then
applications can chose which behaviour they want.  The risk, of course,
is that applications will get this wrong or forgot to add this
additional check.

Another solution may be to introduce 'Ed25519consensus' as a new
algorithm that behave in the ZIP215-reliable way.

/Simon


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

Re: Some ideas for new algorithms in Nettle

[Simon Josefsson]

Joachim Strömbergson  writes:

> I don't know what the idea is in relation to password hashing,
> memory/computational hard functions. PBKDF2 is in Nettle, but not
> bcrypt, scrypt or the PHC winner Argon2. Are there any interest in
> adding them to Nettle?

I have a personal fork of nettle with scrypt support.  I should put it
up somewhere for review and possible inclusion in Nettle.  It is a
clean-room implementation and I did not spend any time on optimization,
so there is room for improvement but I think functionality is more
important as a first step.

/Simon


signature.asc
Description: PGP signature
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

SHAKE

[Simon Josefsson]

Can Nettle compute the SHAKE128/SHAKE256 variant of SHA-3?  What do you
think about adding APIs for them?

/Simon


signature.asc
Description: PGP signature
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [PATCH v2] Please add base-64 URL-safe alphabet

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Amos Jeffries squ...@treenet.co.nz writes:

 I have added a fuzz tester that runs a set of randomly generated strings
 past the default encoder and decoder, then the extended one.

 Nice. It would be good with a couple of short manual examples as well. A
 pity that RFC 4648 doesn't include any testvectors for base64url. (Or am
 I missing something? Simon?)

No, there aren't any -- you can s/+/-/g and s,/,_,g the base64 test
vectors.  Btw, if you produce more complete test vectors, I'd be
interested in adding them to some future update of that document.

/Simon


signature.asc
Description: PGP signature
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: curve25519 progress

[Simon Josefsson]

You wrote:

 I've now pushed some crude code (on the curve25519 branch) which
 agrees with the test vectors in draft-josefsson-tls-curve25519-05.

Wonderful.   There is another document coming out (describing the
Curve25519 algo only) which contains test vectors from the NaCl library
as well, including them would be good.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Curve25519

[Simon Josefsson]

You wrote:

 Nikos Mavrogiannopoulos n...@gnutls.org writes:
 
  It seems it is being pushed forward and openssh even uses it by
  default now.  There are implementations like [0] that nettle could
  take advantage to use that curve, but what I'm worried about is
  that the current interfaces to use this curve provide no agility.
 
 I think you're more familier with its uses than I am. I'm thinking
 that it would be nice to have a 
 
   struct ecc_curve nettle_curve25519;
 
 with the same operations (ecc_point_mul, etc), but maybe a very
 different implementation underneath.

If that is implementable, and sufficient to do ECDH, I think this would
be nice.  Is there any generic (EC)DH interface in nettle?  Maybe
having one would be useful, although maybe the EC math operations in
different curves is sufficient.

 Is that enough? It's not clear to me how people do signatures with
 curve25519, if that's plain ecdsa over a new curve, or something more
 or less different?

There are multiple options, see Ed25519 for a new signing system
EdDSA.  It has some nicer properties than ECDSA but it is also a bit
hardcoded to that curve.  http://ed25519.cr.yp.to/

I don't think it makes sense to add anything about signing in nettle for
new curves until there are practical use cases.  Things are changing
quickly in this space.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: arctwo

[Simon Josefsson]

You wrote:

 Aloha!
 
 Nikos Mavrogiannopoulos wrote:
  However, RC2-40 is used in gnutls to decrypt PKCS #12 files, so it 
  would be good for RC2-40 to remain so that decryption of any
  existing files will remain possible.
 
 Yes, forgot to write about P12 where RC2 can be used. Don't know how
 common it is though.

Last time I looked closely (~3-4 years ago) RC2-40 was quite common
when non-FOSS code were involved (e.g., Windows).  I'm hoping
implementations have been changed since then, but files generated back
then must still be quite common, and thus useful to decrypt.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Camellia reorg

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 For (3), I think Camellia is borderline. It's been implemented in
 Nettle for a couple of releases, but I expect few applications use it.
 And I should also add that applications using nettle_camellia* from
 nettle-meta.h (and do so in the documented way) are unaffected by this
 change.

One way to confirm theories around which applications uses what is to
establish a list of significant applications that uses Nettle, which can
be recompiled with a proposed nettle release to see if they break.  For
you to do this is a lot of work, but maybe just establishing a list of
applications which deserves to be tested against newer nettle is useful
-- then you can ask for volunteers to actually do the testing, and
summarize results.  If nobody steps up for a particular application,
then that particular project has a weaker rationale to complain about
any problems later on.  If projects not on the list complains about
API/ABI breakage, the project can be added to the list.

The above is just an idea, based on my experience with API/ABI breakage
in libraries.  I started out believing that the best approch to API/ABI
rigidity was to do the right thing from a theoretical point of view --
i.e., if there is ABI breakage, bump ABI -- but I've become more
pragmatic over the years.  It seems to cause less problems for everyone
if you make sure the API/ABI is reasonable and works for the majority of
well-maintained packages, even if that sometimes means violating the
theoretical rules around API/ABI version bumping.  The theoretical rules
around API/ABI bumping causes friction and work for a lot of people
every time they are excercised, and overall sometimes that can be
contra-productive.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: ChaCha stream cipher for Nettle available

[Simon Josefsson]

You wrote:

  I can see the need for applications to easily and dynamically change
  from 12 to 14 rounds by simply updating a variable, possibly even a
  loadable value instead of changing the code forcing a recompile.
 
 That's not my experience. The typical crypto application has some
 configuration or protocol handshake to select between aes128-ctr,
 aes256-ctr, salsa20, salsa20r12, etc. For each choice, it needs some
 logic to allocate the right context struct and call the right
 functions (struct nettle_cipher is an example of a minimalistic
 framework to collect that info).
 
 Then, from the application's point of view, salsa20r12 is as different
 from salsa20 as it is from aes128-ctr, none can be be substituted for
 the other except via the algorithm selection procedures, and it really
 doesn't matter which of the different algorithms are unified below
 that algorithm-selection framework.
 
 And the particular change from 12 to 14 might add significant
 complexity to an optimized implementations with 4-way unrolling, so
 flexibility isn't always as cheap as it looks.

I agree -- please just add 20 rounds ChaCha initially.

I am beginning to think that the introducing the 12 rounds Salsa20 was
a really bad/harmful outcome of eSTREAM, as it leads to all these
discussions around number of rounds to support, which slows adoption.
The speed of 20 rounds Salsa20 and ChaCha is high. If speed is more
important than security for someone, I've heard of this nice cipher
called ROT13 that we could probably implement very efficiently.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Switching to size_t

[Simon Josefsson]

I prefer using size_t for all string and data sizes, if for no other reason 
that it is what the C and POSIX standards uses.

/Simon

ni...@lysator.liu.se skrev:

ni...@lysator.liu.se (Niels Möller) writes:

 I think it would make some sense to adopt the principle that key
sizes
 use unsigned (since keys by definition are small objects), and
message
 sizes use size_t.

I'm now leaning towards using size_t also for all function arguments
which are key sizes. There should be no performance penalty in most
cases, and very small penalty also when arguments are passed on the
stack. And it may reduce warnings about truncation to smaller type if
one passes, e.g, the output of strlen. I'll stick to unsigned in struct
nettle_cipher and some of the internal functions, though.

I created the branch size_t-changes, now available also in the public
repo. I think I have converted everything except the unfinished openpgp
code.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: SHA2 renaming

[Simon Josefsson]

fre 2012-11-30 klockan 12:56 +0700 skrev Ivan Shmakov:
  Niels Möller writes:
 
   With support for SHA3, it seems clear that nettle's naming for sha2
   functions was a mistake.  It should be sha2_256, rather than
   sha256.
 
   While such a step would be logical, I'd like to note that while
   SHA-2 algorithms are widely known as SHA-256, etc., it's the
   SHA3-256, etc. forms that seems to be preferred for SHA-3.
 
   There's a logic in keeping the things as they are, too.  When
   SHA-1 was introduced, it supported only 160 bit size digests, so
   there was no need to mention the size explicitly.  When SHA-2
   appeared, it supported several sizes, but none of them coincided
   with the SHA-1's 160 bits, thus the “version” was apparent from
   the bit size.  At last, came SHA-3, and being the later one, it
   has to bear its explicit version number.

I am inclined to agree -- the name SHA256 seems to be more popular
than SHA2-256 or even SHA2 according to Google hits.  Grep RFCs that
use the term SHA256 and that is also the more common usage.  Going
back to the NIST specification:

http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

Quoting:

   This Standard specifies secure hash algorithms - SHA-1, SHA-224,   
   SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 - for
   computing a condensed representation of electronic data (message). 

See also the wikipedia page, it never uses the term sha2-256 but
consistently use the term SHA-256.

http://en.wikipedia.org/wiki/SHA-2

Is there any other authorative sources on SHA2 and what it should be
called?

If the naming in Nettle isn't an obvious mistake, I would prefer not to
change things.  However, I don't really care strongly.

/Simon


___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: SHA2 renaming

[Simon Josefsson]

 Even further than that, I think I'm saying that I would be inclined to
 disagree that SHA256 is a mistaken naming.  What source do you have that
 says the name SHA2-256 is the right name?  From the sources I quoted,
 including FIPS 180-4, the name is SHA256.  I suggest, as a general

Err, I meant SHA-256, not SHA256, of course.

/Simon

___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20/8 and Salsa20/12

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 +void
 +salsa20_core (uint8_t *dst,
 + const uint8_t *src,
 + unsigned rounds)

 is not ideal -- the reason is that the Salsa20 core is not defined with
 a parametrised number of rounds, so the interface is somewhat of a
 bastardisation.

 Naming is difficult, it's awkward to use the prefix salsa20 for a
 function which is salsa20, but not really 20... In sed syntax it would
 be salsa20_sx20xrx ;-)

It could be argued that the name of the function is actually Salsa20
core and that reduced round versions would be Salsa20/r core or
similar.  That would be consistent with the naming scheme for the
Salsa20 stream cipher -- there Salsa20/12 means the Salsa20 stream
cipher but with 12 rounds.  It is not called Salsa12.

 In my work space, I have used the namespace 'salsa20r_core' instead.
 This opens up for later addition of a true 'salsa20_core' function which
 would use the official 20 rounds.

 What do you think?

 I have no better suggestions for naming. But if we think of
 salsa20r_core as mostly for internal use, maybe we don't need it?

 If I understood you correctly, your primary use case is scrypt, which
 you intend to implement in Nettle? Then maybe you would be better off
 without an extra wrapper function around _salsa20_core? If nothing else,
 you could then make sure you have proper alignment so you don't need an
 extra memcpy.

 I hesitate a bit to add, document and support a new obscure function
 until there's a clear external use case.

Good points.  Generally, I think it would be nice to have public
interfaces for the Salsa20 core function, but currently there really
aren't any use-cases for it except for scrypt that I am aware of.  The
conservative approach then is to not expose it right now.

What is driving this particular patch, though, is that the scrypt code
needs a salsa20 core function that takes uint8_t's and return uint8_t's.
I think there are two ways to address that need:

 1) Implement the salsa20r_core uint8_t function in the scrypt file.

 2) Add another internal function in salsa20.h that implement the
 uint8_t interface.

I prefer the second alternative, because then the implementation is done
in the right place if there is ever another need for the salsa20 core
uint8_t interface within Nettle (or externally).  Thoughts?

I'm thinking it could be something like:

void
_salsa20_core8(uint8_t *dst, const uint8_t *src, unsigned rounds);

possibly the current _salsa20_core should be renamed _salsa20_core32 for
consistency.  Having the uint32_t interface be called _salsa20_core even
if it is an internal function seems a bit confusing -- the proper
interface to it is uint8_t's.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20/8 and Salsa20/12

[Simon Josefsson]

Daniel Kahn Gillmor d...@fifthhorseman.net writes:

   /* _salsa20_core does any needed byteswapping of the output. A memcpy
  is needed to support unaligned dst; simply casting like
  _salsa20_core ((uint32_t *) dst, src32, rounds) is not portable. */
   memcpy (dst, dst32, sizeof (dst32));

 Thanks, that's now tested and make check passes on both powerpc and i386.

Thanks for testing.  I was about to update this patch too, but then it
occured to me that this interface:

 +void
 +salsa20_core (uint8_t *dst,
 +   const uint8_t *src,
 +   unsigned rounds)

is not ideal -- the reason is that the Salsa20 core is not defined with
a parametrised number of rounds, so the interface is somewhat of a
bastardisation.

In my work space, I have used the namespace 'salsa20r_core' instead.
This opens up for later addition of a true 'salsa20_core' function which
would use the official 20 rounds.

What do you think?

The patch below is update to apply against latest master.

/Simon
From d33b64426e34818c9297de22bfd2cf80daa9472b Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Wed, 28 Nov 2012 02:42:53 +0100
Subject: [PATCH] Add salsa20r_core function.

---
 ChangeLog|9 
 Makefile.in  |2 +-
 NEWS |2 ++
 nettle.texinfo   |6 +
 salsa20-core.c   |   55 ++
 salsa20.h|5 +
 testsuite/salsa20-test.c |   36 ++
 7 filer ändrade, 114 tillägg(+), 1 borttagning(-)
 create mode 100644 salsa20-core.c

diff --git a/ChangeLog b/ChangeLog
index 3c38a0d..0299403 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2012-11-06  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention Salsa20 core.
+	* nettle.texinfo: Document salsa20r_core.
+	* Makefile.in (nettle_SOURCES): Add salsa20-core.c.
+	* salsa20.h (salsa20r_core): Add.
+	* salsa20-core.c: New file.
+	* testsuite/salsa20-test.c (test_main): Self-check salsa20r_core.
+
 2012-11-15  Niels Möller  ni...@lysator.liu.se
 
 	* sha3-permute.c (sha3_permute): Use ULL suffix on round
diff --git a/Makefile.in b/Makefile.in
index c30149b..8372def 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -84,7 +84,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 gosthash94.c \
 		 ripemd160.c ripemd160-compress.c ripemd160-meta.c \
 		 salsa20-core-internal.c \
-		 salsa20-crypt.c salsa20-set-key.c \
+		 salsa20-crypt.c salsa20-core.c salsa20-set-key.c \
 		 sha1.c sha1-compress.c sha1-meta.c \
 		 sha256.c sha256-compress.c sha224-meta.c sha256-meta.c \
 		 sha512.c sha512-compress.c sha384-meta.c sha512-meta.c \
diff --git a/NEWS b/NEWS
index 35439e2..8613056 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,8 @@ NEWS for the 2.6 release
 	  More information in RFC4357. Test vectors taken from the GOST
 	  hash wikipedia page.
   
+	* Support for the Salsa20 core.  Contributed by Simon
+  Josefsson.
 
 NEWS for the 2.5 release
 
diff --git a/nettle.texinfo b/nettle.texinfo
index ea4b158..e79b81f 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -1378,6 +1378,12 @@ all but the last call @emph{must} use a length that is a multiple of
 
 @end deftypefun
 
+@deftypefun void salsa20r_core (uint8_t *@var{dst}, const uint8_t *@var{src}, unsigned @var{rounds})
+Hash the 64-byte (@code{SALSA20_BLOCK_SIZE}) message into a 64-byte
+message, using the indicated number of Salsa20 core rounds.
+
+@end deftypefun
+
 @subsection SERPENT
 SERPENT is one of the AES finalists, designed by Ross Anderson, Eli
 Biham and Lars Knudsen. Thus, the interface and properties are similar
diff --git a/salsa20-core.c b/salsa20-core.c
new file mode 100644
index 000..a5c37d1
--- /dev/null
+++ b/salsa20-core.c
@@ -0,0 +1,55 @@
+/* salsa20-core.c
+ *
+ * The Salsa20 core hash.
+ */
+
+/* nettle, low-level cryptographics library
+ *
+ * Copyright (C) 2012 Simon Josefsson
+ *
+ * The nettle library is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or (at your
+ * option) any later version.
+ *
+ * The nettle library 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 Lesser General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with the nettle library; see the file COPYING.LIB.  If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02111-1301, USA.
+ */
+
+#if HAVE_CONFIG_H
+# include config.h
+#endif
+
+#include string.h
+
+#include salsa20.h
+
+#include macros.h
+#include memxor.h
+
+void
+salsa20r_core (uint8_t *dst,
+	   const uint8_t *src

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 --- a/pbkdf2.h
 +++ b/pbkdf2.h
 @@ -35,6 +35,8 @@ extern C
  
  /* Namespace mangling */
  #define pbkdf2 nettle_pbkdf2
 +#define pbkdf2_hmac_sha1 nettle_pbkdf2_sha1
 +#define pbkdf2_hmac_sha256 nettle_pbkdf2_sha256

 I changed the symbols to nettle_pbkdf2_hmac_sha1 and
 nettle_pbkdf2_hmac_sha256. I take it the abbreviation was unintentional?

Right, sorry about that.  Thank you!

I'll proceed cleaning up the Salsa code next, to reach my goal of having
scrypt in here as well (I have it working on
https://www.gitorious.org/scrypt/nettle-scrypt).

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Salsa20 core

[Simon Josefsson]

I realized that I didn't have any use for the round-reduced Salsa20
stream functions.  So I'll focus on what I needed instead, which
resulted in a much smaller patch.  What do you think?  Open issues:

* I'm not particular happy about the name SALSA20_CORE_INOUT_SIZE.

* Where could this be documented in the manual?  Miscellaneous
  functions?  We could also create a new section Non-cryptographic
  Hash functions.  There is the FNV and CRC hashes that could be
  implemented under that umbrella.

/Simon
From 94ed050615fc0435df797da422a665652e8018fd Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Fri, 21 Sep 2012 10:21:22 +0200
Subject: [PATCH] Support Salsa20 core.

---
 Makefile.in  |2 +-
 salsa20-core.c   |   74 ++
 salsa20.h|7 +
 testsuite/salsa20-test.c |   14 +
 4 files changed, 96 insertions(+), 1 deletion(-)
 create mode 100644 salsa20-core.c

diff --git a/Makefile.in b/Makefile.in
index 9904be5..24d9446 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -82,7 +82,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 md2.c md2-meta.c md4.c md4-meta.c \
 		 md5.c md5-compress.c md5-compat.c md5-meta.c \
 		 ripemd160.c ripemd160-compress.c ripemd160-meta.c \
-		 salsa20-crypt.c salsa20-set-key.c \
+		 salsa20-crypt.c salsa20-set-key.c salsa20-core.c \
 		 sha1.c sha1-compress.c sha1-meta.c \
 		 sha256.c sha256-compress.c sha224-meta.c sha256-meta.c \
 		 sha512.c sha512-compress.c sha384-meta.c sha512-meta.c \
diff --git a/salsa20-core.c b/salsa20-core.c
new file mode 100644
index 000..67895cc
--- /dev/null
+++ b/salsa20-core.c
@@ -0,0 +1,74 @@
+/* salsa20-core.c
+ *
+ * The Salsa20 core hash function.
+ */
+
+/* nettle, low-level cryptographics library
+ *
+ * Copyright (C) 2012 Simon Josefsson
+ *
+ * The nettle library is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or (at your
+ * option) any later version.
+ *
+ * The nettle library 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 Lesser General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with the nettle library; see the file COPYING.LIB.  If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02111-1301, USA.
+ */
+
+/* Based on salsa20-crypt.c. */
+
+#if HAVE_CONFIG_H
+# include config.h
+#endif
+
+#include string.h
+
+#include salsa20.h
+
+#include macros.h
+
+#define QROUND(x0, x1, x2, x3) do { \
+  x1 ^= ROTL32(7, x0 + x3);	\
+  x2 ^= ROTL32(9, x1 + x0);	\
+  x3 ^= ROTL32(13, x2 + x1);	\
+  x0 ^= ROTL32(18, x3 + x2);	\
+  } while(0)
+
+void
+salsa20_core (unsigned rounds,
+	  uint8_t dst[SALSA20_CORE_INOUT_SIZE],
+	  const uint8_t src[SALSA20_CORE_INOUT_SIZE])
+{
+  uint32_t x[SALSA20_CORE_INOUT_SIZE / sizeof (uint32_t)];
+  unsigned i;
+
+  for (i = 0; i  SALSA20_CORE_INOUT_SIZE / sizeof (uint32_t); i++)
+x[i] = LE_READ_UINT32(src[i * 4]);
+
+  for (i = 0; i  rounds; i += 2)
+{
+  QROUND(x[0], x[4], x[8], x[12]);
+  QROUND(x[5], x[9], x[13], x[1]);
+  QROUND(x[10], x[14], x[2], x[6]);
+  QROUND(x[15], x[3], x[7], x[11]);
+
+  QROUND(x[0], x[1], x[2], x[3]);
+  QROUND(x[5], x[6], x[7], x[4]);
+  QROUND(x[10], x[11], x[8], x[9]);
+  QROUND(x[15], x[12], x[13], x[14]);
+}
+
+  for (i = 0; i  SALSA20_CORE_INOUT_SIZE / sizeof (uint32_t); i++)
+{
+  uint32_t t = x[i] + LE_READ_UINT32(src[i * 4]);
+  LE_WRITE_UINT32(dst[i * sizeof (uint32_t)], t);
+}
+}
diff --git a/salsa20.h b/salsa20.h
index 7d47f52..f13fd3d 100644
--- a/salsa20.h
+++ b/salsa20.h
@@ -45,6 +45,8 @@ extern C {
 #define SALSA20_KEY_SIZE 32
 #define SALSA20_BLOCK_SIZE 64
 
+#define SALSA20_CORE_INOUT_SIZE 64
+
 #define SALSA20_IV_SIZE 8
 
 #define _SALSA20_INPUT_LENGTH 16
@@ -75,6 +77,11 @@ salsa20_crypt(struct salsa20_ctx *ctx,
 	  unsigned length, uint8_t *dst,
 	  const uint8_t *src);
 
+/* Salsa20 core. */
+void
+salsa20_core (unsigned rounds, uint8_t dst[SALSA20_CORE_INOUT_SIZE],
+	  const uint8_t src[SALSA20_CORE_INOUT_SIZE]);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/testsuite/salsa20-test.c b/testsuite/salsa20-test.c
index d742ce4..f89d3ce 100644
--- a/testsuite/salsa20-test.c
+++ b/testsuite/salsa20-test.c
@@ -177,6 +177,20 @@ test_salsa20(const struct tstring *key,
 void
 test_main(void)
 {
+  uint8_t dst[SALSA20_CORE_INOUT_SIZE];
+
+  /* http://tools.ietf.org/html/draft-josefsson-scrypt-kdf */
+
+  salsa20_core (8, dst, H(7e879a214f3ec9867ca940e641718f26
+			  baee555b8c61c1b50df846116dcd3b1d

Re: Salsa20 core

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 * I'm not particular happy about the name SALSA20_CORE_INOUT_SIZE.

 Just use SALSA20_BLOCK_SIZE. It's the same thing, right?

It is the same value at least.  I'll use it.

 * Where could this be documented in the manual?  Miscellaneous
   functions?  We could also create a new section Non-cryptographic
   Hash functions.

 I think it would make sense to put it in the salsa section, possibly
 with a reference from the section on hash functions and any other place
 where it may be relevant. As I understand it, it *is* like a
 cryptographic function, but with a fixed input size.

No, it is not a cryptographic hash function since it is not
collision-resistant.  Think of it as CRC or FNV.

 What about assembly implementation? Do you think that is desirable? I
 think it should be fairly easy. Start with x86_64/salsa20-crypt.asm,
 move the QROUND macro to some other file (and maybe define some
 additional macros for shared code). And write a new salsa20-core.asm,
 which can be pretty simple, in particular, it doesn't need the complex
 code for handling partial blocks.

Right.  I considered it, as a way to learn to assembler stuff in Nettle.
However, I'm not sure there is a lot to gain, since there is no loop
unrolling to speak off.  But it could be considered.

 +void
 +salsa20_core (unsigned rounds,
 +  uint8_t dst[SALSA20_CORE_INOUT_SIZE],
 +  const uint8_t src[SALSA20_CORE_INOUT_SIZE])

 You settled on uint8_t input, rather than uint32_t? IIRC, the
 corresponding function in the salsa20 paper is defined with uint32_t
 array as input and an uint8_t array as output. 

 I guess little endian byte order of the input (matching the byte order for
 the output) is the only sensible choice? This ought to be clearly
 documented somewhere.

Yes.  I'm struggling with this aspect.  The only canonical resource I
have been able to find on the Salsa20 core function is this page:

http://cr.yp.to/salsa20.html

It says clearly:

   The Salsa20 core is a function from 64-byte strings to 64-byte
   strings: the Salsa20 core reads a 64-byte string x and produces a
   64-byte string Salsa20(x).

and

   The 64-byte input x to Salsa20 is viewed in little-endian form as 16
   words x0, x1, x2, ..., x15 in {0,1,...,2^32-1}. ... producing, in
   little-endian form, the 64-byte output Salsa20(x).

So little endian and byte input/output is clearly intended.

The page goes on to show code that takes and return uint32_t and does no
endian conversion.  It says that this is the callers responsibility, so
we can assume this is intended to be included in the definition.

However, the Salsa20 stream cipher seems to use the core function with
uint32_t inputs, and scrypt does too.  So perhaps we should expose a
uint32_t-uint32_t interface as well that does no endian conversion.  It
seems scrypt doesn't little endian convert inputs but expects the output
uint32_t to be little endian converted though...  I'll bring this up
with Colin.

 In nettle I currently don't use array types for function arguments. If
 you write them as arrays, like you do here, do current compilers make
 any use that for bounds checking, or do you just think it's clearer for
 humans?

I've always regarded it as something intended for humans.  I'm not sure
what a compiler could do with the information.  Perhaps it could be
useful for optimizations though.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20 core

[Simon Josefsson]

Simon Josefsson si...@josefsson.org writes:

 However, the Salsa20 stream cipher seems to use the core function with
 uint32_t inputs, and scrypt does too.  So perhaps we should expose a
 uint32_t-uint32_t interface as well that does no endian conversion.  It
 seems scrypt doesn't little endian convert inputs but expects the output
 uint32_t to be little endian converted though...  I'll bring this up
 with Colin.

Nope, I was mistaken.

Still it seems that an uint32_t-uint32_t interface without endian
conversion may be beneficial for speed.  Then scrypt won't have to
convert from uint32_t to uint8_t just to have salsa convert from uint8_t
to uint32_t back again, do the operation and convert it from uint32_t to
uint8_t and have scrypt convert it from uint8_t to uint32_t.  I haven't
measured how much overhead endian conversion really consumes though.

Do you think a uint32_t-uint32_t interface would be acceptable?
Externally the uint32 interface could be seen as a convenience function,
although internally it would be the core and the uint8_t interface would
just do endian conversion.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20 core

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 Do you think a uint32_t-uint32_t interface would be acceptable?

 If that's what is really needed for scrypt (the only application so
 far), and it lets you avoid converting back and forth between bytes and
 uint32_t, then it seems like the right thing to do.

 We may add a function with uint8_t (and little endian convention, I
 guess) later if the need arises. So we should take that possibility into
 account when naming the function.

So you don't think we should implement the uint8_t interface now?  I
think there is little cost in doing that directly, and allows us to
directly use the only test vectors that I'm aware of.

What's a good name?  Is there any precedent for something like this in
Nettle?

void
salsa20_core (unsigned rounds,
  uint8_t dst[SALSA20_BLOCK_SIZE],
  const uint8_t src[SALSA20_BLOCK_SIZE])

void
salsa20_core32 (unsigned rounds,
uint32_t dst[SALSA20_INPUT_LENGTH],
const uint32_t src[SALSA20_INPUT_LENGTH])

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20 core

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 No, it is not a cryptographic hash function since it is not
 collision-resistant.  Think of it as CRC or FNV.

 I'd like to understand better the properties of Salsa. As I see it, we
 have a complicated non-linear, but easily invertible, permutation on
 blocks of 64 bytes (or 512 bits). Call this function P(X). Then we
 construct a hash function

   F(X) = X xor P(X)

There is no XOR in the Salsa20 core?

 and scrypt does too.

 Reading the internet draft, it looks like it treats input and output as
 64 bytes. I haven't read any other scrypt materials.

Yes, the draft treat it that way because the function appears to be
defined that way.  The scrypt paper does too
(http://www.tarsnap.com/scrypt/scrypt.pdf).

 It seems scrypt doesn't little endian convert inputs but expects the
 output uint32_t to be little endian converted though... I'll bring
 this up with Colin.

 Please do, this needs to be sorted out.

I was mistaken, scrypt uses the uint32_t interface directly and (as
epxected) without any endian conversion.

 In nettle I currently don't use array types for function arguments.

 I've always regarded it as something intended for humans.  I'm not sure
 what a compiler could do with the information.  Perhaps it could be
 useful for optimizations though.

 I tend to use pointer notation, because (1) it's what really happens,
 (2) it's shorter to write, and (3) because arrays may give a casual
 reader the impression that something more complicated happens. Neither
 is a very good reason, but for now I think we should stick to pointers
 for consistency within Nettle. If arrays notation is better, we should
 change that in all places where we pass arrays of constant size.

No problem, I've made this change locally.  Once we sort out the naming
issue I'll submit another patch.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20 core

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 I'd like to understand better the properties of Salsa. As I see it, we
 have a complicated non-linear, but easily invertible, permutation on
 blocks of 64 bytes (or 512 bits). Call this function P(X). Then we
 construct a hash function

   F(X) = X xor P(X)

 There is no XOR in the Salsa20 core?

 Sorry, the final operation is addition (applied independently to 32 bit
 pieces), not xor. But structure is the same, P(X) represents the QROUND
 loop, where each step is invertible, and then at the end we add together
 the output of the QROUNDs and the original input. Collisions are
 introduced in the final addition, in the sense that we have

   P(x) == P(y) if and only if x = y

 but F(x) = F(y) is possible for x != y. A collision means that

   P(x) xor x == P(y) xor y

 which can be rearrange, since P is invertible, as

   x = P^{-1}(x xor y xor P(y)

 Examples of such colliding pairs seem non-trivial to find (difficulty
 increasing wth the number of rounds).

 You write that the function is not collision resistant. I'd like to know
 in which way it fails (ideally with either a simple argument, or a
 reference).

Try for example:

  salsa20_core (8, dst, H(
  
  
  ));
  print_hex(64, dst);

  salsa20_core (8, dst, H(0080008000800080
  0080008000800080
  0080008000800080
  0080008000800080));
  print_hex(64, dst);

both will print the all-zero string, thus illustrating a collision.  In
fact, Salsa20core(x) = Salsa20core(x + c) for c = 00080008

See also:

https://groups.google.com/forum/?fromgroups=#!msg/sci.crypt/AkQnSoO40BA/o4eG96rjkgYJ
http://cr.yp.to/snuffle/reoncore-20080224.pdf

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20 core

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 So you don't think we should implement the uint8_t interface now?  I
 think there is little cost in doing that directly, and allows us to
 directly use the only test vectors that I'm aware of.

 I don't have a strong opinion. If it helps testing, and we are confident
 that it should be little-endian, let's add it.

 What's a good name?  Is there any precedent for something like this in
 Nettle?

 If we look at internal building blocks, there are a couple of examples:
 gcm_hash, and sha1_compress (and similar compression functions for other
 hashes). Neither of those are advertised/documented.

 I think it would make sense to call the uint32_t function salsa_core,
 and the uint8_t function salsa_hash. We'll see if we can sort out what
 properties it really has, but it definitely has important similarities
 to a hash function.

It is a hash function, just not a cryptographic hash function.

Below is an updated patch.  What do you think?

/Simon
From 306cb60ec971aaf36afae99de1183a12838e9f90 Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Fri, 21 Sep 2012 10:21:22 +0200
Subject: [PATCH] Support Salsa20 core.

---
 ChangeLog|9 +
 Makefile.in  |2 +-
 NEWS |3 ++
 salsa20-core.c   |  100 ++
 salsa20.h|   12 +-
 testsuite/salsa20-test.c |   29 ++
 6 files changed, 152 insertions(+), 3 deletions(-)
 create mode 100644 salsa20-core.c

diff --git a/ChangeLog b/ChangeLog
index efb578e..683e828 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2012-09-21  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention Salsa20 core.
+	* salsa20.h (salsa20_core, salsa20_hash): Add prototypes.
+	(_SALSA20_INPUT_LENGTH): Rename to SALSA20_INPUT_LENGTH.
+	* salsa20-core.c: New file.
+	* Makefile.in (nettle_SOURCES): Add salsa20-core.c
+	* testsuite/salsa20-test.c (test_main): Test Salsa20 core.
+
 2012-09-20  Simon Josefsson  si...@josefsson.org
 
 	* pbkdf2-hmac-sha1.c, pbkdf2-hmac-sha256.c: New files.
diff --git a/Makefile.in b/Makefile.in
index 9904be5..24d9446 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -82,7 +82,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 md2.c md2-meta.c md4.c md4-meta.c \
 		 md5.c md5-compress.c md5-compat.c md5-meta.c \
 		 ripemd160.c ripemd160-compress.c ripemd160-meta.c \
-		 salsa20-crypt.c salsa20-set-key.c \
+		 salsa20-crypt.c salsa20-set-key.c salsa20-core.c \
 		 sha1.c sha1-compress.c sha1-meta.c \
 		 sha256.c sha256-compress.c sha224-meta.c sha256-meta.c \
 		 sha512.c sha512-compress.c sha384-meta.c sha512-meta.c \
diff --git a/NEWS b/NEWS
index 8f7e9e6..a40d6cc 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,9 @@ NEWS for the 2.6 release
 
 	New features:
 
+	* Support for the Salsa20 core.  Contributed by Simon
+  Josefsson.
+
 	* Support for PKCS #5 PBKDF2.  Contributed by Simon Josefsson.
   Specification in RFC 2898 and test vectors in RFC 6070.
 
diff --git a/salsa20-core.c b/salsa20-core.c
new file mode 100644
index 000..a579bb1
--- /dev/null
+++ b/salsa20-core.c
@@ -0,0 +1,100 @@
+/* salsa20-core.c
+ *
+ * The Salsa20 core hash function.
+ */
+
+/* nettle, low-level cryptographics library
+ *
+ * Copyright (C) 2012 Simon Josefsson
+ *
+ * The nettle library is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or (at your
+ * option) any later version.
+ *
+ * The nettle library 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 Lesser General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with the nettle library; see the file COPYING.LIB.  If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02111-1301, USA.
+ */
+
+/* Based on salsa20-crypt.c. */
+
+#if HAVE_CONFIG_H
+# include config.h
+#endif
+
+#include string.h
+
+#include salsa20.h
+
+#include macros.h
+
+#define QROUND(x0, x1, x2, x3) do { \
+  x1 ^= ROTL32(7, x0 + x3);	\
+  x2 ^= ROTL32(9, x1 + x0);	\
+  x3 ^= ROTL32(13, x2 + x1);	\
+  x0 ^= ROTL32(18, x3 + x2);	\
+  } while(0)
+
+static void
+_salsa20 (unsigned rounds,
+	  uint32_t *x)
+{
+  unsigned i;
+
+  for (i = 0; i  rounds; i += 2)
+{
+  QROUND(x[0], x[4], x[8], x[12]);
+  QROUND(x[5], x[9], x[13], x[1]);
+  QROUND(x[10], x[14], x[2], x[6]);
+  QROUND(x[15], x[3], x[7], x[11]);
+
+  QROUND(x[0], x[1], x[2], x[3]);
+  QROUND(x[5], x[6], x[7], x[4]);
+  QROUND(x[10], x[11], x[8], x[9]);
+  QROUND(x[15], x

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 ni...@lysator.liu.se (Niels Möller) writes:

 Thanks. Checked in now. Hope I got all the pieces.

 Turned out I forgot to commit your test case. Fixed now.

 I've also done the suggested reordering of the arguments (including the
 prototype in the manual).

Thank you.

 Could you add that, or should I submit a patch?

 A patch including tests and documentation would be very nice. Your
 prototype looks right to me,

void
pbkdf2_hmac_sha1 (unsigned key_length, const uint8_t *key,
  unsigned iterations,
  unsigned salt_length, const uint8_t *salt,
  unsigned length, uint8_t *dst)

 The declarations can go i pbkdf2.h, with implementation in separate source
 files pkbdf2-hmac-sha1.c and -sha256.c.

See patch below.  I also improved the manual a bit.

/Simon
From cfad97cf3bd005e13051f359d6afa23d9cda8c41 Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Thu, 20 Sep 2012 22:41:17 +0200
Subject: [PATCH] Implement concrete PBKDF2 functions.

---
 ChangeLog   |9 
 Makefile.in |2 +-
 nettle.texinfo  |   55 ++-
 pbkdf2-hmac-sha1.c  |   45 ++
 pbkdf2-hmac-sha256.c|   45 ++
 pbkdf2.h|   16 ++
 testsuite/pbkdf2-test.c |   17 +++
 7 files changed, 183 insertions(+), 6 deletions(-)
 create mode 100644 pbkdf2-hmac-sha1.c
 create mode 100644 pbkdf2-hmac-sha256.c

diff --git a/ChangeLog b/ChangeLog
index 049c3dd..efb578e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2012-09-20  Simon Josefsson  si...@josefsson.org
+
+	* pbkdf2-hmac-sha1.c, pbkdf2-hmac-sha256.c: New files.
+	* pbkdf2.h (pbkdf2_hmac_sha1, pbkdf2_hmac_sha256): New prototypes.
+	* Makefile.in (nettle_SOURCES): Add pbkdf2-hmac-sha1.c and
+	pbkdf2-hmac-sha256.c.
+	* nettle.texinfo (Key derivation functions): Improve.
+	* testsuite/pbkdf2-test.c (test_main): Test new functions.
+
 2012-09-20  Niels Möller  ni...@lysator.liu.se
 
 	* pbkdf2.c (pbkdf2): Reordered arguments, for consistency.
diff --git a/Makefile.in b/Makefile.in
index 7c6cf33..9904be5 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -77,7 +77,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 des3.c des-compat.c \
 		 hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
 		 hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
-		 pbkdf2.c \
+		 pbkdf2.c pbkdf2-hmac-sha1.c pbkdf2-hmac-sha256.c \
 		 knuth-lfib.c \
 		 md2.c md2-meta.c md4.c md4-meta.c \
 		 md5.c md5-compress.c md5-compat.c md5-meta.c \
diff --git a/nettle.texinfo b/nettle.texinfo
index a333779..c73861b 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -2123,12 +2123,19 @@ a given symmetric key derives other symmetric keys.  A sub-class of KDFs
 is the @dfn{password-based key derivation functions} (@acronym{PBKDFs}),
 which take as input a password or passphrase, and its purpose is
 typically to strengthen it and protect against certain pre-computation
-attacks by using salting and expensive computation.  The most well known
-PBKDF is the @code{PKCS #5 PBKDF2} described in @cite{RFC 2898} which
-uses a pseudorandom function such as @acronym{HMAC-SHA1}.
+attacks by using salting and expensive computation.
 
-Nettle's @acronym{PBKDF2} function is defined in @file{nettle/pbkdf2.h}.
-It contains a function:
+@subsection @acronym{PBKDF2}
+The most well known PBKDF is the @code{PKCS #5 PBKDF2} described in
+@cite{RFC 2898} which uses a pseudorandom function such as
+@acronym{HMAC-SHA1}.
+
+Nettle's @acronym{PBKDF2} functions are defined in
+@file{nettle/pbkdf2.h}.  There is an abstract function that operate on
+any PRF implemented via the @code{nettle_hash_update_func},
+@code{nettle_hash_digest_func} interfaces.  There is also helper macros
+and concrete functions PBKDF2-HMAC-SHA1 and PBKDF2-HMAC-SHA256.  First,
+the abstract function:
 
 @deftypefun void pbkdf2 (void *mac_ctx, nettle_hash_update_func *update, nettle_hash_digest_func *digest, unsigned digest_size, unsigned iterations, unsigned salt_length, const uint8_t *salt, unsigned length, uint8_t *dst)
 Derive symmetric key from a password according to PKCS #5 PBKDF2.  The
@@ -2141,6 +2148,44 @@ desired derived output length @var{length}.  The output buffer is
 @var{dst} which must have room for at least @var{length} octets.
 @end deftypefun
 
+Like for CBC and HMAC, there is a macros to help use the functions
+correctly.
+
+@deffn Macro PBKDF2 (@var{ctx}, @var{update}, @var{digest}, @var{digest_size}, @var{iterations}, @var{salt_length}, @var{salt}, @var{length}, @var{dst})
+@var{ctx} is a pointer to a context struct passed to the @var{update}
+and @var{digest} functions (of the types @code{nettle_hash_update_func}
+and @code{nettle_hash_digest_func} respectively

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 However, I suppose this complexity could be hidden with a utility
 function 'pbkdf2_hmac' that is similar to my original function
 signature.

 Do you think a half-general pbkdf2_hmac function really is useful? I
 think specific wrapper functions, pbkdf2_hmac_sha256, etc, would be more
 useful.

I agree.  PBKDF2-HMAC-SHA1 is the most important.  If there is also
support for PBKDF2-HMAC-SHA256 then all usual cases are handled.  I
would actually hesistate to add convenience functions for the rest since
it may lead people to use them without thinking that there are costs in
using a new variant.  I feel even PBKDF2-HMAC-SHA256 is wasteful, there
is nothing cryptographically wrong with PBKDF2-HMAC-SHA1, but that is an
uphill battle to fight...

 This is a problem shared with almost every function in nettle accepting
 function pointer arguments. I think we have to live with casts one way
 or the other; I don't see any good solution.

Aha.  I hadn't realized that.

 Casting the parameter would solve this.  Is there any other way to
 resolve the warning?  Do you think casting is an acceptable solution
 here?  The problem seems to be that the casting needs to happen in the
 application not in the library.

 At least specific functions like pbkdf2_hmac_sha256 functions will not
 expose the problem to users. It's also possible to write some macros to
 do the cast but preserve some type checking, something like

 #define PBKDF2(ctx, update, digest, ...) \
  (0 ? (update(ctx, 0, NULL), digest(ctx, 0, NULL)) \
 : pbkdf(ctx, (nettle_hash_update_func *) update, (nettle_hash_digest_func 
 *) digest, ..,))
  
 The CBC_ENCRYPT and CBC_DECRYPT macros do this, and it seems to work
 fine, but it's not particularly pretty.

 Any other ideas?

This approach seems fine to me.

 Thanks for the implementation, I'll try to get it integrated soon. Some
 minor comments (which I can fix):

I can submit an updated patch if that would speed things up.  Recall
that the ChangeLog, manual etc was not updated for the new interface in
my most recent patch, so there is some cleaning up to do.

 --- a/nettle-internal.h
 +++ b/nettle-internal.h
 @@ -48,6 +48,7 @@ do { if (size  (sizeof(name) / sizeof(name[0])))
 abort(); } while (0)
  #define NETTLE_MAX_BIGNUM_SIZE ((NETTLE_MAX_BIGNUM_BITS + 7)/8)
  #define NETTLE_MAX_HASH_BLOCK_SIZE 128
  #define NETTLE_MAX_HASH_DIGEST_SIZE 64
 +#define NETTLE_MAX_HASH_CONTEXT_SIZE 216
  #define NETTLE_MAX_SEXP_ASSOC 17
  #define NETTLE_MAX_CIPHER_BLOCK_SIZE 32

 This is no longer needed, right?

Once the next issue is fixed, agreed.

 +void
 +pbkdf2 (void *mac_ctx, unsigned digest_size,
 +nettle_hash_update_func *update,
 +nettle_hash_digest_func *digest,
 +unsigned length, uint8_t *dst,
 +unsigned iterations,
 +unsigned salt_length, const uint8_t *salt)
 +{
 +  char U[NETTLE_MAX_HASH_DIGEST_SIZE];
 +  char T[NETTLE_MAX_HASH_DIGEST_SIZE];

 It would make sense to use TMP_ALLOC for those. And I think I'd use uint8_t
 rather than char (unless there's some reason for char I'm missing?).

Agreed.  It was copy'n'paste from my old implementation.

 +  tmp[0] = (i  0xff00)  24;
 +  tmp[1] = (i  0x00ff)  16;
 +  tmp[2] = (i  0xff00)  8;
 +  tmp[3] = (i  0x00ff)  0;

 There's WRITE_UINT32 for this.

Great.  Same reason here.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 I can submit an updated patch if that would speed things up.  Recall
 that the ChangeLog, manual etc was not updated for the new interface in
 my most recent patch, so there is some cleaning up to do.

 If you can make an updated patch for manual and ChangeLog, that'd be
 great. I'll take care of the code.

Here it is.

Thanks,
/Simon
From f3d3ee482dd6b908b988d33a25ef1118d54b42db Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Tue, 18 Sep 2012 09:44:08 +0200
Subject: [PATCH] Add support for PKCS#5 PBKDF2.

---
 ChangeLog  |   12 ++
 Makefile.in|2 +
 NEWS   |6 +++
 nettle.texinfo |   43 +++-
 pbkdf2.c   |   95 
 pbkdf2.h   |   51 
 testsuite/.gitignore   |1 +
 testsuite/.test-rules.make |3 ++
 testsuite/Makefile.in  |2 +-
 testsuite/meta-hash-test.c |1 +
 testsuite/pbkdf2-test.c|   73 ++
 11 files changed, 286 insertions(+), 3 deletions(-)
 create mode 100644 pbkdf2.c
 create mode 100644 pbkdf2.h
 create mode 100644 testsuite/pbkdf2-test.c

diff --git a/ChangeLog b/ChangeLog
index f2a2010..fad906d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2012-09-12  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention addition of PBKDF2.
+	* pbkdf2.c (pbkdf2): New file and function.
+	* pbkdf2.h: Declare it.
+	* Makefile.in (nettle_SOURCES): Add pbkdf2.c.
+	(HEADERS): Add pbkdf2.h.
+	* nettle.texinfo (Key derivation functions): New section.
+	* testsuite/pbkdf2-test.c: New test case.
+	* testsuite/Makefile.in (TS_NETTLE_SOURCES): Add pbkdf2-test.c.
+	* testsuite/.test-rules.make (pbkdf2-test): New target.
+
 2012-09-16  Niels Möller  ni...@lysator.liu.se
 
 	* testsuite/: Overhaul of testsuite, affecting almost all files.
diff --git a/Makefile.in b/Makefile.in
index cf93593..7c6cf33 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -77,6 +77,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 des3.c des-compat.c \
 		 hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
 		 hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
+		 pbkdf2.c \
 		 knuth-lfib.c \
 		 md2.c md2-meta.c md4.c md4-meta.c \
 		 md5.c md5-compress.c md5-compat.c md5-meta.c \
@@ -123,6 +124,7 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h bignum.h blowfish.h \
 	  cbc.h ctr.h gcm.h \
 	  des.h des-compat.h dsa.h \
 	  hmac.h \
+	  pbkdf2.h \
 	  knuth-lfib.h \
 	  macros.h \
 	  md2.h md4.h \
diff --git a/NEWS b/NEWS
index 4957f80..ea846a7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,9 @@
+
+	New features:
+
+	* Support for PKCS #5 PBKDF2.  Contributed by Simon Josefsson.
+  Specification in RFC 2898 and test vectors in RFC 6070.
+
 NEWS for the 2.5 release
 
 	This release includes important portability fixes for Windows
diff --git a/nettle.texinfo b/nettle.texinfo
index 4904d91..39f3c68 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -70,6 +70,7 @@ Reference
 * Cipher functions::
 * Cipher modes::
 * Keyed hash functions::
+* Key derivation functions::
 * Public-key algorithms::   
 * Randomness::  
 * Ascii encoding::  
@@ -199,6 +200,10 @@ implementation (in the public domain), adapted to Nettle by Simon
 Josefsson, and heavily modified by Niels Möller. Assembly for x86_64 by
 Niels Möller. Released under the LGPL.
 
+@item PBKDF2
+The C implementation of PBKDF2 is based on earlier work for Shishi and
+GnuTLS by Simon Josefsson.  Released under the LGPL.
+
 @item SERPENT
 The implementation of the SERPENT cipher is based on the code in libgcrypt,
 copyright owned by the Free Software Foundation. Adapted to Nettle by
@@ -316,6 +321,7 @@ This chapter describes all the Nettle functions, grouped by family.
 * Cipher functions::
 * Cipher modes::
 * Keyed hash functions::
+* Key derivation functions::
 * Public-key algorithms::   
 * Randomness::  
 * Ascii encoding::  
@@ -1852,7 +1858,7 @@ only the first @var{length} octets of the digest are written.
 
 
 
-@node Keyed hash functions, Public-key algorithms, Cipher modes, Reference
+@node Keyed hash functions, Key derivation functions, Cipher modes, Reference
 @comment  node-name,  next,  previous,  up
 @section Keyed Hash Functions
 
@@ -2102,7 +2108,40 @@ This function also resets the context for processing new messages, with
 the same key.
 @end deftypefun
 
-@node Public-key algorithms, Randomness, Keyed hash functions, Reference
+@node Key derivation functions, Public-key algorithms, Keyed hash functions, Reference
+@comment  node-name,  next,  previous,  up
+@section Key derivation Functions
+
+@cindex Key Derivation Function
+@cindex Password Based Key

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 ni...@lysator.liu.se (Niels Möller) writes:

 If you can make an updated patch for manual and ChangeLog, that'd be
 great. I'll take care of the code.

 Here it is.

 Thanks. Checked in now. Hope I got all the pieces. I also added a PBKDF2
 macro with the casting tricks.

Thank you!

 And a pbkdf2_hmac_sha1 function can now be implemented as follows:

   void
   pbkdf2_hmac_sha1 (unsigned key_length, const uint8_t *key,
 unsigned length, uint8_t *dst,
 unsigned iterations,
 unsigned salt_length, const uint8_t *salt)
   {
 struct hmac_sha1_ctx ctx;
 hmac_sha1_set_key (ctx, key_length, key);
 PBKDF2 (ctx, SHA1_DIGEST_SIZE, hmac_sha1_update, hmac_sha1_digest,
 length, dst, iterations, salt_length, salt);
   }

Could you add that, or should I submit a patch?  I think having
pbkdf2_hmac_sha256 as well would be good, but no others.

 Any final interface tweaks? Is the order of the arguments sensible and
 consistent with other nettle interfaces? I.e., currently

   void
   pbkdf2 (void *mac_ctx, unsigned digest_size,
   nettle_hash_update_func *update,
   nettle_hash_digest_func *digest,
   unsigned length, uint8_t *dst,
   unsigned iterations,
   unsigned salt_length, const uint8_t *salt);

 Hmm, looking at cbc_encrypt/cbc_decrypt, it might be more consistent to
 (1) put digest_size after the function pointers, and (2) put the length,
 dst arguments last (this depends a bit on whether or not one wants to
 think of the salt as an src input or as some auxillary parameter. At
 east the iteration count should go earlier in the list. So maybe

   void
   pbkdf2 (void *mac_ctx,
   nettle_hash_update_func *update,
   nettle_hash_digest_func *digest,
   unsigned digest_size,
   unsigned iterations,
   unsigned salt_length, const uint8_t *salt,
   unsigned length, uint8_t *dst);

 What do you think? This *is* nit-picking, but interface consistency is
 important and this is the right time to tweak it.

I prefer this new variant.  The pbkdf2_hmac_* functions should follow
this pattern too, so it would be:

   void
   pbkdf2_hmac_sha1 (unsigned key_length, const uint8_t *key,
 unsigned iterations,
 unsigned salt_length, const uint8_t *salt,
 unsigned length, uint8_t *dst)

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

Simon Josefsson si...@josefsson.org writes:

 Is there any other open issue?  I could update the patch to work with
 the new testsuite interface, if that would help review.

Preparing an updated patch was easy, here it is and should apply to git
master.  This improves on a few minor issues compared to the old patch.

/Simon
From a0e9fabe97896ac0b80638472b62b3340b0a4425 Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Tue, 18 Sep 2012 09:44:08 +0200
Subject: [PATCH] Add support for PKCS#5 PBKDF2.

---
 ChangeLog  |   14 ++
 Makefile.in|2 +
 NEWS   |6 +++
 nettle-internal.h  |1 +
 nettle.texinfo |   42 +-
 pbkdf2.c   |  103 
 pbkdf2.h   |   49 +
 testsuite/.gitignore   |1 +
 testsuite/.test-rules.make |3 ++
 testsuite/Makefile.in  |2 +-
 testsuite/meta-hash-test.c |3 ++
 testsuite/pbkdf2-test.c|   49 +
 12 files changed, 272 insertions(+), 3 deletions(-)
 create mode 100644 pbkdf2.c
 create mode 100644 pbkdf2.h
 create mode 100644 testsuite/pbkdf2-test.c

diff --git a/ChangeLog b/ChangeLog
index f2a2010..cc3f661 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2012-09-12  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention addition of PBKDF2.
+	* pbkdf2.c (pbkdf2_hmac): New file and function.
+	* pbkdf2.h: Declare it.
+	* Makefile.in (nettle_SOURCES): Add pbkdf2.c.
+	(HEADERS): Add pbkdf2.h.
+	* nettle-internal.h (NETTLE_MAX_HASH_CONTEXT_SIZE): New constant.
+	* nettle.texinfo (Key derivation functions): New section.
+	* testsuite/pbkdf2-test.c: New test case.
+	* testsuite/meta-hash-test.c (test_main): Validate NETTLE_MAX_HASH_CONTEXT_SIZE.
+	* testsuite/Makefile.in (TS_NETTLE_SOURCES): Add pbkdf2-test.c.
+	* testsuite/.test-rules.make (pbkdf2-test): New target.
+
 2012-09-16  Niels Möller  ni...@lysator.liu.se
 
 	* testsuite/: Overhaul of testsuite, affecting almost all files.
diff --git a/Makefile.in b/Makefile.in
index cf93593..7c6cf33 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -77,6 +77,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 des3.c des-compat.c \
 		 hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
 		 hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
+		 pbkdf2.c \
 		 knuth-lfib.c \
 		 md2.c md2-meta.c md4.c md4-meta.c \
 		 md5.c md5-compress.c md5-compat.c md5-meta.c \
@@ -123,6 +124,7 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h bignum.h blowfish.h \
 	  cbc.h ctr.h gcm.h \
 	  des.h des-compat.h dsa.h \
 	  hmac.h \
+	  pbkdf2.h \
 	  knuth-lfib.h \
 	  macros.h \
 	  md2.h md4.h \
diff --git a/NEWS b/NEWS
index 4957f80..ea846a7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,9 @@
+
+	New features:
+
+	* Support for PKCS #5 PBKDF2.  Contributed by Simon Josefsson.
+  Specification in RFC 2898 and test vectors in RFC 6070.
+
 NEWS for the 2.5 release
 
 	This release includes important portability fixes for Windows
diff --git a/nettle-internal.h b/nettle-internal.h
index e85e3c5..510909b 100644
--- a/nettle-internal.h
+++ b/nettle-internal.h
@@ -48,6 +48,7 @@ do { if (size  (sizeof(name) / sizeof(name[0]))) abort(); } while (0)
 #define NETTLE_MAX_BIGNUM_SIZE ((NETTLE_MAX_BIGNUM_BITS + 7)/8)
 #define NETTLE_MAX_HASH_BLOCK_SIZE 128
 #define NETTLE_MAX_HASH_DIGEST_SIZE 64
+#define NETTLE_MAX_HASH_CONTEXT_SIZE 216
 #define NETTLE_MAX_SEXP_ASSOC 17
 #define NETTLE_MAX_CIPHER_BLOCK_SIZE 32
 
diff --git a/nettle.texinfo b/nettle.texinfo
index 4904d91..a8fd233 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -70,6 +70,7 @@ Reference
 * Cipher functions::
 * Cipher modes::
 * Keyed hash functions::
+* Key derivation functions::
 * Public-key algorithms::   
 * Randomness::  
 * Ascii encoding::  
@@ -199,6 +200,10 @@ implementation (in the public domain), adapted to Nettle by Simon
 Josefsson, and heavily modified by Niels Möller. Assembly for x86_64 by
 Niels Möller. Released under the LGPL.
 
+@item PBKDF2
+The C implementation of PBKDF2 is based on earlier work for Shishi and
+GnuTLS by Simon Josefsson.  Released under the LGPL.
+
 @item SERPENT
 The implementation of the SERPENT cipher is based on the code in libgcrypt,
 copyright owned by the Free Software Foundation. Adapted to Nettle by
@@ -316,6 +321,7 @@ This chapter describes all the Nettle functions, grouped by family.
 * Cipher functions::
 * Cipher modes::
 * Keyed hash functions::
+* Key derivation functions::
 * Public-key algorithms::   
 * Randomness::  
 * Ascii encoding::  
@@ -1852,7 +1858,7 @@ only the first @var{length} octets of the digest are written.
 
 
 
-@node Keyed hash functions, Public-key algorithms, Cipher modes, Reference
+@node Keyed hash functions, Key

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 +void
 +pbkdf2_hmac (unsigned Plen, const uint8_t * P,
 + unsigned Slen, const uint8_t * S,
 + const struct nettle_hash *hash,
 + unsigned int c, unsigned dkLen, uint8_t * DK);

 Maybe it would make more sense for pbkdf2 to use an arbitrary mac?

Yes, PBKDF2 is actually defined to apply to any PRF generally.

 The caller would provide the mac an dinitialize it with the
 password. And then the pbkdf2 functions takes the mac, the salt,
 count, and generates the key. Like

   void
   pbkdf2 (void *mac_ctx, unsigned digest_size,
   nettle_hash_update_func *update,
   nettle_hash_digest_func *digest,
   unsigned length, uint8_t *dst,
   unsigned iterations,
   unsigned salt_length, const uint8_t *salt);

This feels a bit inconsistent with the hmac interface, but it is
slightly more general.  In practice, I'm not aware of anyone using
PBKDF2 with anything non-HMAC though.

 Example usage:

   hmac_sha1_ctx ctx;
   uint8_t key[57];
   
   hmac_sha1_set_key (ctx, 8, password);
   pbkdf2 (ctx, SHA1_DIGEST_SIZE, hmac_sha1_update, hmac_sha1_digest,
 sizeof(key), key,
   4711, 6, pepper);

 Would that make sense? I guess one may also want some convenience
 macros/functions for using hmac-sha1 etc.

I suppose this would work. PBKDF2 invokes the PRF many times with
different inputs (however always with the same key).  It seems
hmac_sha1_digest reset the context for new use.

Do you want me to submit an updated patch?

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 Did you notice that testsuite/meta-hash-test.c was modified as well to
 make sure the magic number is OK?

 Yes, that's good, but I'd still prefer to have it defined in terms of sizeof.

 A sizeof or sizeof-union could work
 too, but then nettle-internal.h would need more #include's.

 Since it's for internal use only, I don't think that's a problem. And
 including sha.h should be sufficient I guess? (I still haven't checked,
 but I would think sha512_ctx is the largest one).

The sizes are:

md2: 84
md4: 92
md5: 92
ripemd160: 96
sha1: 96
sha224: 108
sha256: 108
sha384: 216
sha512: 216

Do you want me to use this approach in any updated patch?

 +  TMP_DECL (inner, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE);
 +  TMP_DECL (outer, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE);
 +  TMP_DECL (state, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE);

 [...]

 Ah, no reason really.  I wrote the inner/outer/state part later, after
 settling on the nettle_hash abstraction, so this was code inspired by
 hmac.c.  I found the hmac interface a bit odd here, so there may be
 better ways to do this.

 Hmm. I don't think using TMP_DECL like that is right. If HAVE_ALLOCA,
 then it's going to be a plain alloca, which is what we really want. The
 problem is the fallback case, when we don't use allloca. Then it expands
 to

   uint8_t inner[NETTLE_MAX_HASH_CONTEXT_SIZE];

 which may not be properly aligned.

 We shouldn't use malloc here, so if we can't think up something
 completely different, I think nettle-internal.h needs to define some
 union type which makes the C compiler to provide sufficient space and
 proper alignment. Somewhat like sockaddr_storage.

 And the hmac code uses TMP_DECL/TMP_ALLOC for input blocks and digests,
 not for the context structs.

 (Maybe it should be designed differently? I'll send a separate reply on
 that).

I'm hoping this issue goes away with your new proposed interface, I
think it does.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Salsa20/8 and Salsa20/12

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 I quickly discovered that I needed the round-reduced variants of
 Salsa20.  Here they are.  I didn't update the assembler part, so I would
 need help finishing that part.

 Nice. Key setup is the same, just the number of iterations in the main
 loop is different?

Yes.

 +static void
 +salsa20r_crypt(struct salsa20_ctx *ctx,
 +   int rounds,
 +   unsigned length,
 +   uint8_t *c,
 +   const uint8_t *m)

 This is the function which should be implemented in assembly.

Actually, sleeping on this, I realized that we really want to export the
Salsa20 core primitive (this was what I actually needed), and that is
the primitive that should be implemented in assembler.  I've fixed this
in the attached patch.

The Salsa20 core is a hash function (not your typical hash function
though) described here:

http://cr.yp.to/salsa20.html

If we implement that quickly in assembler, with a variable round
parameter, that will be sufficient to build fast C code around.

All of the Salsa20, Salsa20/8, Salsa20/12 and the stream handling code
could then be written in C.

 Do you think this should be a public, documented function (in which
 case salsa20r_crypt sounds like a reasonable name), or internal, in
 which case nettle convention would be something like _salsa20_crypt?

It should be an internal function, I've fixed this in the patch below.

 --- a/testsuite/salsa20-test.c
 +++ b/testsuite/salsa20-test.c
 @@ -13,13 +13,18 @@ memzero_p (const uint8_t *p, size_t n)
return 1;
  }
  
 +typedef void (*salsa20_func) (struct salsa20_ctx *ctx,
 +  unsigned length, uint8_t *dst,
 +  const uint8_t *src);
 +

 A very minor point... I've decided to try to stick to non-pointer
 typedefs for function types. I.e.,

   typedef void salsa20_func (struct salsa20_ctx *ctx,
unsigned length, uint8_t *dst,
const uint8_t *src);

 That way, it is possible (although maybe not useful very often) to use
 the typedef for declaring functions, like

   salsa20_func salsa20_crypt;
   salsa20_func salsa20r8_crypt;
   salsa20_func salsa20r12_crypt;

Sure.

Updated patch below.

/Simon
From 0edbad4db412f42321801a23e12d1931fe36b40c Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Thu, 13 Sep 2012 23:55:38 +0200
Subject: [PATCH] Support Salsa20 core and round-reduced Salsa20/8 and
 Salsa20/12.

---
 ChangeLog|   12 ++
 NEWS |5 +++
 salsa20-crypt.c  |   91 +++---
 salsa20.h|   18 
 testsuite/salsa20-test.c |  108 --
 5 files changed, 194 insertions(+), 40 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fe61ad9..c4c7d57 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2012-09-14  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention Salsa20 core, Salsa20/8 and Salsa20/12.
+	* salsa20.h (salsa20r8_crypt): New prototype.
+	(salsa20r12_crypt): New prototype.
+	(salsa20_core): New prototype.
+	* salsa20-crypt.c (salsa20r8_crypt): New function.
+	(salsa20r12_crypt): New function.
+	(salsa20_core): New function.
+	(salsa20r_crypt): New function.
+	* testsuite/salsa20-test.c: Test new functions.
+
 2012-09-10  Niels Möller  ni...@lysator.liu.se
 
 	* examples/eratosthenes.c (main): Explicitly deallocate storage
diff --git a/NEWS b/NEWS
index 4957f80..6baddd0 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,8 @@
+	New features:
+
+	* Support for the Salsa20 core and round-reduced Salsa20/8 and
+  Salsa20/12.
+
 NEWS for the 2.5 release
 
 	This release includes important portability fixes for Windows
diff --git a/salsa20-crypt.c b/salsa20-crypt.c
index eae3cea..c7ba863 100644
--- a/salsa20-crypt.c
+++ b/salsa20-crypt.c
@@ -56,42 +56,54 @@
   } while(0)
 
 void
-salsa20_crypt(struct salsa20_ctx *ctx,
-	  unsigned length,
-	  uint8_t *c,
-	  const uint8_t *m)
+salsa20_core (uint32_t src[_SALSA20_INPUT_LENGTH],
+	  uint32_t dst[_SALSA20_INPUT_LENGTH],
+	  unsigned rounds)
+{
+  uint32_t x[_SALSA20_INPUT_LENGTH];
+  unsigned i;
+
+  memcpy (x, src, sizeof(x));
+  for (i = 0;i  rounds;i += 2)
+{
+  QROUND(x[0], x[4], x[8], x[12]);
+  QROUND(x[5], x[9], x[13], x[1]);
+  QROUND(x[10], x[14], x[2], x[6]);
+  QROUND(x[15], x[3], x[7], x[11]);
+
+  QROUND(x[0], x[1], x[2], x[3]);
+  QROUND(x[5], x[6], x[7], x[4]);
+  QROUND(x[10], x[11], x[8], x[9]);
+  QROUND(x[15], x[12], x[13], x[14]);
+}
+
+  for (i = 0;i  _SALSA20_INPUT_LENGTH;++i)
+{
+  uint32_t t = x[i] + src[i];
+  dst[i] = LE_SWAP32 (t);
+}
+}
+
+static void
+_salsa20_crypt(struct salsa20_ctx *ctx,
+	   int rounds,
+	   unsigned length,
+	   uint8_t *c,
+	   const uint8_t *m)
 {
   if (!length)
 return

Re: Salsa20/8 and Salsa20/12

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 Actually, sleeping on this, I realized that we really want to export the
 Salsa20 core primitive (this was what I actually needed), and that is
 the primitive that should be implemented in assembler.  I've fixed this
 in the attached patch.

 The Salsa20 core is a hash function (not your typical hash function
 though) described here:

 I guess it could be named salsa20_hash, then? (I think there was such a
 function in a previous version of the code).

The name of the hash is Salsa20 core but I think little effort has
gone into tightening up the documentation around the Salsa20 hash (for
example, there are no test vectors that I could find).  salsa20_hash
works for me, but could be confusing as it isn't a normal hash.

 If we implement that quickly in assembler, with a variable round
 parameter, that will be sufficient to build fast C code around.

 Then you'd first write the hash output to memory, then read it back to
 xor it with the message. Since sals20 is pretty fast, I think you'll get
 a measurablle performance penalty compared to the currrent code which
 keeps the hash output in registers until it is xored to the message.

Right, good point.

 You really need to get just the hash output, without xoring it to
 anything?

Yes, although if necessary I could xor it to a zero buffer if there were
no other way...  however I'll loose performance, and my application
(scrypt) would benefit from good performance.

 It would definitely be cleaner to have the hash function separately.

I agree.

 +salsa20_core (uint32_t src[_SALSA20_INPUT_LENGTH],
 +  uint32_t dst[_SALSA20_INPUT_LENGTH],
 +  unsigned rounds)
 [...]
 +  for (i = 0;i  _SALSA20_INPUT_LENGTH;++i)
 +{
 +  uint32_t t = x[i] + src[i];
 +  dst[i] = LE_SWAP32 (t);
 +}
 +}

 This makes for a very peculiar interface for a non-internal function. It
 would make more sense from an interface perspectivve to either not do
 these byte swaps, or have the output parameter be of type uint8_t *. Or
 do something like the union gcm_block in gcm.h (although that's also not
 pretty), if we want to be able to store the byte swapped value with a
 word-sized store.

Let's use uint8_t.  The first sentence of the Salsa20 core webpage is:

   The Salsa20 core is a function from 64-byte strings to 64-byte
   strings: the Salsa20 core reads a 64-byte string x and produces a
   64-byte string Salsa20(x).

So that is consistent with uint8_t.

 I don't remember precisely the background of the current implementation,
 but I think the point was to do as much as possible of the processing as
 word operations, including the byte swapping.

Yes that will be faster I suppose.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 How about adding KDFs?  Here is a starting pointer for the most common
 function, PKCS #5 PBKDF2.  Review appreciated.

 I don't have time to review it at the moment, but I hope to be able to do
 that within a few days. You may also want to have a look at

 http://git.lysator.liu.se/lsh/lsh/blobs/master/src/pkcs5.c

 which I wrote a long time ago. Probably not very useful for Nettle as
 is, but I'll happily relicense it as LGPL if anything is derived from it.

Possibly the block_count stuff could be used, although I'm not sure how
it works: if you have a large dkLen wouldn't more than the final octet
be needed?

 One immediate comment: PBKDF2 is an awful name :-/

Yes...

 Are there any other key derivation methods which are important?

Widely used KDF's include the OpenPGP s2k, TLS (different variants),
Kerberos.  More recent KDF's include HKDF and scrypt.  I'm sure there
are more.

However, I'm not certain 1) it makes sense to implement several KDFs in
nettle, 2) whether an generic interface can be found.  Re 2) it seems
KDFs are highly parametrized for its specialized purpose, and thus
require special parameters.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 Possibly the block_count stuff could be used, although I'm not sure how
 it works: if you have a large dkLen wouldn't more than the final octet
 be needed?

 In general, one could have something larger. In lsh I use it only for
 encrypted private keys, and then I don't need anything larger than, say
 256 bits key and 128 bits iv.

Ah.  I have some uses that require long outputs, and a generic
implementation should support that.

 However, I'm not certain 1) it makes sense to implement several KDFs in
 nettle,

 I imagine main use would be to decrypt alien password-encrypted data.
 E.g., gpg keyrings and private keys for any other tools (what is
 openssh using?) So any method which is used in more than one
 non-obscure application would make some sense to support.

Not all KDFs are password-based, though, but I think it is the
password-based KDFs that are most useful to support in the near term.
HKDF is a recent strong candidate though.

 2) whether an generic interface can be found.

 I don't think we need to worry about a generic interface now. I was more
 thinking about proper naming for the non-generic interface. E.g, can we
 say pkcs5 rather than pbdwhatever, or are there other methods
 defined in pkcs#5 (or likely to be in the future)? Naming should be
 reasonable now, and still not break down if we add other methods later.

PKCS#5 specify an obsolete PBKDF1 as well, and several other algorithms,
so PKCS#5 as a name is not that unique.  Possibly pkcs5_pbkdf2_hmac
would be more precise, although it is longer.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Salsa20/8 and Salsa20/12

[Simon Josefsson]

I quickly discovered that I needed the round-reduced variants of
Salsa20.  Here they are.  I didn't update the assembler part, so I would
need help finishing that part.

/Simon
From 0d15d69c41456dfb1fc7b6317d4e9fd00a444ab3 Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Thu, 13 Sep 2012 23:55:38 +0200
Subject: [PATCH] Support round-reduced Salsa20/8 and Salsa20/12.

---
 ChangeLog|   10 +
 NEWS |5 +++
 salsa20-crypt.c  |   40 ++---
 salsa20.h|   12 ++
 testsuite/salsa20-test.c |  108 --
 5 files changed, 155 insertions(+), 20 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fe61ad9..8ca5395 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2012-09-13  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention Salsa20/8 and Salsa20/12.
+	* salsa20.h (salsa20r8_crypt): New prototype.
+	(salsa20r12_crypt): New prototype.
+	* salsa20-crypt.c (salsa20r8_crypt): New function.
+	(salsa20r12_crypt): New function.
+	(salsa20r_crypt): New function, move logic from salsa20_crypt.
+	* testsuite/salsa20-test.c: Test new functions.
+
 2012-09-10  Niels Möller  ni...@lysator.liu.se
 
 	* examples/eratosthenes.c (main): Explicitly deallocate storage
diff --git a/NEWS b/NEWS
index 4957f80..8a96752 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,8 @@
+	New features:
+
+	* Support for the round-reduced Salsa20/8 and Salsa20/12
+  variants.
+
 NEWS for the 2.5 release
 
 	This release includes important portability fixes for Windows
diff --git a/salsa20-crypt.c b/salsa20-crypt.c
index eae3cea..a57cb71 100644
--- a/salsa20-crypt.c
+++ b/salsa20-crypt.c
@@ -55,11 +55,12 @@
   x0 ^= ROTL32(18, x3 + x2);	\
   } while(0)
 
-void
-salsa20_crypt(struct salsa20_ctx *ctx,
-	  unsigned length,
-	  uint8_t *c,
-	  const uint8_t *m)
+static void
+salsa20r_crypt(struct salsa20_ctx *ctx,
+	   int rounds,
+	   unsigned length,
+	   uint8_t *c,
+	   const uint8_t *m)
 {
   if (!length)
 return;
@@ -69,7 +70,7 @@ salsa20_crypt(struct salsa20_ctx *ctx,
   uint32_t x[_SALSA20_INPUT_LENGTH];
   int i;
   memcpy (x, ctx-input, sizeof(x));
-  for (i = 0;i  10;i ++)
+  for (i = 0;i  rounds;i += 2)
 	{
 	  QROUND(x[0], x[4], x[8], x[12]);
 	  QROUND(x[5], x[9], x[13], x[1]);
@@ -104,3 +105,30 @@ salsa20_crypt(struct salsa20_ctx *ctx,
   m += SALSA20_BLOCK_SIZE;
   }
 }
+
+void
+salsa20_crypt(struct salsa20_ctx *ctx,
+	  unsigned length,
+	  uint8_t *c,
+	  const uint8_t *m)
+{
+  salsa20r_crypt(ctx, 20, length, c, m);
+}
+
+void
+salsa20r8_crypt(struct salsa20_ctx *ctx,
+	  unsigned length,
+	  uint8_t *c,
+	  const uint8_t *m)
+{
+  salsa20r_crypt(ctx, 8, length, c, m);
+}
+
+void
+salsa20r12_crypt(struct salsa20_ctx *ctx,
+		 unsigned length,
+		 uint8_t *c,
+		 const uint8_t *m)
+{
+  salsa20r_crypt(ctx, 12, length, c, m);
+}
diff --git a/salsa20.h b/salsa20.h
index 7d47f52..ebb28c7 100644
--- a/salsa20.h
+++ b/salsa20.h
@@ -75,6 +75,18 @@ salsa20_crypt(struct salsa20_ctx *ctx,
 	  unsigned length, uint8_t *dst,
 	  const uint8_t *src);
 
+/* Round-reduced Salsa20/8. */
+void
+salsa20r8_crypt(struct salsa20_ctx *ctx,
+		unsigned length, uint8_t *dst,
+		const uint8_t *src);
+
+/* Round-reduced Salsa20/12. */
+void
+salsa20r12_crypt(struct salsa20_ctx *ctx,
+		 unsigned length, uint8_t *dst,
+		 const uint8_t *src);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/testsuite/salsa20-test.c b/testsuite/salsa20-test.c
index 7a246b9..8ec6c25 100644
--- a/testsuite/salsa20-test.c
+++ b/testsuite/salsa20-test.c
@@ -13,13 +13,18 @@ memzero_p (const uint8_t *p, size_t n)
   return 1;
 }
 
+typedef void (*salsa20_func) (struct salsa20_ctx *ctx,
+			  unsigned length, uint8_t *dst,
+			  const uint8_t *src);
+
 /* The ecrypt testcases encrypt 512 zero bytes (8 blocks), then give
the xor of all blocks, and the data for block 0 (0-43), 3,4
(192-319), 7 (448-511) */
 
 #define STREAM_LENGTH 512
 static void
-test_salsa20_stream(unsigned key_length,
+test_salsa20_stream(salsa20_func crypt,
+		unsigned key_length,
 		const uint8_t *key,
 		const uint8_t *iv,
 		const uint8_t *ciphertext,
@@ -34,7 +39,7 @@ test_salsa20_stream(unsigned key_length,
   salsa20_set_key(ctx, key_length, key);
   salsa20_set_iv(ctx, iv);
   memset(stream, 0, STREAM_LENGTH + 1);
-  salsa20_crypt(ctx, STREAM_LENGTH, stream, stream);
+  crypt(ctx, STREAM_LENGTH, stream, stream);
   if (stream[STREAM_LENGTH])
 {
   fprintf(stderr, Stream of %d bytes wrote too much!\n, STREAM_LENGTH);
@@ -90,7 +95,7 @@ test_salsa20_stream(unsigned key_length,
 {
   memset(data, 0, STREAM_LENGTH + 1);
   salsa20_set_iv(ctx, iv);
-  salsa20_crypt(ctx, j, data, data);
+  crypt(ctx, j, data, data);
 
   if (!MEMEQ(j, data, stream))
 	{
@@ -114,7 +119,8 @@ test_salsa20_stream(unsigned key_length

[PATCH] PKCS #5 PBKDF2

[Simon Josefsson]

How about adding KDFs?  Here is a starting pointer for the most common
function, PKCS #5 PBKDF2.  Review appreciated.

/Simon
From 2fe9180d4b0afb7acb77622d541d5be21830fc7b Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Wed, 12 Sep 2012 22:05:30 +0200
Subject: [PATCH] New PKCS #5 PBKDF2 function.

---
 ChangeLog  |   14 ++
 Makefile.in|2 +
 NEWS   |6 +++
 nettle-internal.h  |1 +
 nettle.texinfo |   38 +++-
 pbkdf2.c   |  103 
 pbkdf2.h   |   49 +
 testsuite/.gitignore   |1 +
 testsuite/.test-rules.make |3 ++
 testsuite/Makefile.in  |2 +-
 testsuite/meta-hash-test.c |3 ++
 testsuite/pbkdf2-test.c|   51 ++
 12 files changed, 270 insertions(+), 3 deletions(-)
 create mode 100644 pbkdf2.c
 create mode 100644 pbkdf2.h
 create mode 100644 testsuite/pbkdf2-test.c

diff --git a/ChangeLog b/ChangeLog
index fe61ad9..a35f747 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2012-09-12  Simon Josefsson  si...@josefsson.org
+
+	* NEWS: Mention addition of PBKDF2.
+	* pbkdf2.c (pbkdf2_hmac): New file and function.
+	* pbkdf2.h: Declare it.
+	* Makefile.in (nettle_SOURCES): Add pbkdf2.c.
+	(HEADERS): Add pbkdf2.h.
+	* testsuite/pbkdf2-test.c: New test case.
+	* nettle-internal.h (NETTLE_MAX_HASH_CONTEXT_SIZE): New constant.
+	* testsuite/meta-hash-test.c (test_main): Validate NETTLE_MAX_HASH_CONTEXT_SIZE.
+	* nettle.texinfo (Key derivation functions): New section.
+	* testsuite/Makefile.in (TS_NETTLE_SOURCES): Add pbkdf2-test.c.
+	* testsuite/.test-rules.make (pbkdf2-test): New target.
+
 2012-09-10  Niels Möller  ni...@lysator.liu.se
 
 	* examples/eratosthenes.c (main): Explicitly deallocate storage
diff --git a/Makefile.in b/Makefile.in
index cf93593..7c6cf33 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -77,6 +77,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 		 des3.c des-compat.c \
 		 hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
 		 hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
+		 pbkdf2.c \
 		 knuth-lfib.c \
 		 md2.c md2-meta.c md4.c md4-meta.c \
 		 md5.c md5-compress.c md5-compat.c md5-meta.c \
@@ -123,6 +124,7 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h bignum.h blowfish.h \
 	  cbc.h ctr.h gcm.h \
 	  des.h des-compat.h dsa.h \
 	  hmac.h \
+	  pbkdf2.h \
 	  knuth-lfib.h \
 	  macros.h \
 	  md2.h md4.h \
diff --git a/NEWS b/NEWS
index 4957f80..ea846a7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,9 @@
+
+	New features:
+
+	* Support for PKCS #5 PBKDF2.  Contributed by Simon Josefsson.
+  Specification in RFC 2898 and test vectors in RFC 6070.
+
 NEWS for the 2.5 release
 
 	This release includes important portability fixes for Windows
diff --git a/nettle-internal.h b/nettle-internal.h
index e85e3c5..a7a37f8 100644
--- a/nettle-internal.h
+++ b/nettle-internal.h
@@ -48,6 +48,7 @@ do { if (size  (sizeof(name) / sizeof(name[0]))) abort(); } while (0)
 #define NETTLE_MAX_BIGNUM_SIZE ((NETTLE_MAX_BIGNUM_BITS + 7)/8)
 #define NETTLE_MAX_HASH_BLOCK_SIZE 128
 #define NETTLE_MAX_HASH_DIGEST_SIZE 64
+#define NETTLE_MAX_HASH_CONTEXT_SIZE 2
 #define NETTLE_MAX_SEXP_ASSOC 17
 #define NETTLE_MAX_CIPHER_BLOCK_SIZE 32
 
diff --git a/nettle.texinfo b/nettle.texinfo
index 4904d91..d887ed9 100644
--- a/nettle.texinfo
+++ b/nettle.texinfo
@@ -70,6 +70,7 @@ Reference
 * Cipher functions::
 * Cipher modes::
 * Keyed hash functions::
+* Key derivation functions::
 * Public-key algorithms::   
 * Randomness::  
 * Ascii encoding::  
@@ -316,6 +317,7 @@ This chapter describes all the Nettle functions, grouped by family.
 * Cipher functions::
 * Cipher modes::
 * Keyed hash functions::
+* Key derivation functions::
 * Public-key algorithms::   
 * Randomness::  
 * Ascii encoding::  
@@ -1852,7 +1854,7 @@ only the first @var{length} octets of the digest are written.
 
 
 
-@node Keyed hash functions, Public-key algorithms, Cipher modes, Reference
+@node Keyed hash functions, Key derivation functions, Cipher modes, Reference
 @comment  node-name,  next,  previous,  up
 @section Keyed Hash Functions
 
@@ -2102,7 +2104,39 @@ This function also resets the context for processing new messages, with
 the same key.
 @end deftypefun
 
-@node Public-key algorithms, Randomness, Keyed hash functions, Reference
+@node Key derivation functions, Public-key algorithms, Keyed hash functions, Reference
+@comment  node-name,  next,  previous,  up
+@section Key derivation Functions
+
+@cindex Key Derivation Function
+@cindex Password Based Key Derivation Function
+@cindex PKCS #5
+@cindex KDF
+@cindex PBKDF
+
+A @dfn{key derivation function} (@acronym{KDF}) is a function that from
+a given symmetric key

Re: [PATCH] some patches to fix compiler warnings

[Simon Josefsson]

Tim Ruehsen tim.rueh...@gmx.de writes:

 As Simon Josefsson made clear, the main reason are automated tests for memory 
 leaks using valgrind. Something, that a library test suite should not miss.
...
 But without freeing resources in main(), you now can't easily say, if
 you have a problem in the library or in the testsuite.

However, as far as I recall, the Nettle library does not contain any
calls to malloc or other memory allocating functions.  So I don't think
there could be any memory leaks from the library?

If it is a huge effort to release memory from the testsuite, it may not
be worth it.  But if it is a small effort, and it leads to being able to
run all the testsuite under valgrind without any warnings, I would
support doing it.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Salsa20

[Simon Josefsson]

Hi!  Please find attached a port of DJB's public domain code for Salsa20
to nettle.  The patch is not meant to be applied as-is but to start a
discussion.  Review of the code itself is welcome.

While writing this I noticed a sub-optimal design of Nettle, in that it
overloads the meaning of struct nettle_cipher-block_size as a flag of
whether the cipher is a stream cipher or not.  Before arcfour was the
only stream cipher in nettle, and using block_size=0 to signal that it
is a stream cipher worked fine.  However, Salsa20 has a block size of 8
bytes.  Another odd thing is that Salsa20 requires an IV.  So some
changes to the nettle_cipher struct are required.

This could be resolved better than I have done in the patch below.  I
see two reasonable alternatives:

1) Introduce a new struct 'struct nettle_stream_cipher' that applies to
stream ciphers and use that.

2) Add a flag in 'struct nettle_cipher' to tell whether the cipher is a
stream cipher or not.

I started out strongly prefering 1) because it appeared cleaner.  After
thinking about the changes required to implement that, I am now leaning
towards 2) because of:

A) a lot of code would have to be duplicated if we have both 'struct
nettle_cipher' and 'struct nettle_stream_cipher' for apparently little
gain.  Otherwise, most code could be the same, and where the distinction
matters there could be a simple if-test.

B) it allows for full backwards compatibility in a clean way.  With 1)
we would have a transition period where people switch arcfour usage from
nettle_cipher to nettle_stream_cipher.  With 2) arcfour would continue
to have block_size==0 but it would also set the new stream cipher flag.
External code could incrementally be updated to check the new flag
instead of block_size==0 (if it does that at all) but that is something
that doesn't uglify nettle.

What do you think?  I'd be happy to propose a patch to implement 2) and
then a follow-on patch to add support for Salsa20.

/Simon

From 600ae2815634ad95c4d2d93821316ce20df19ae3 Mon Sep 17 00:00:00 2001
From: Simon Josefsson si...@josefsson.org
Date: Wed, 21 Mar 2012 17:06:13 +0100
Subject: [PATCH] Implement Salsa20.

---
 Makefile.in  |3 +-
 examples/nettle-benchmark.c  |3 +
 nettle-meta-ciphers.c|2 +
 nettle-meta.h|8 ++-
 nettle-types.h   |5 +
 salsa20-meta.c   |   49 
 salsa20.c|  172 ++
 salsa20.h|   71 +
 testsuite/.gitignore |1 +
 testsuite/.test-rules.make   |3 +
 testsuite/Makefile.in|1 +
 testsuite/meta-cipher-test.c |2 +
 testsuite/salsa20-test.c |   49 
 testsuite/testutils.c|   36 +++--
 testsuite/testutils.h|   10 +++
 15 files changed, 407 insertions(+), 8 deletions(-)
 create mode 100644 salsa20-meta.c
 create mode 100644 salsa20.c
 create mode 100644 salsa20.h
 create mode 100644 testsuite/salsa20-test.c

diff --git a/Makefile.in b/Makefile.in
index 1813a0d..6e2ec60 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -79,6 +79,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
 md2.c md2-meta.c md4.c md4-meta.c \
 md5.c md5-compress.c md5-compat.c md5-meta.c \
 ripemd160.c ripemd160-compress.c ripemd160-meta.c \
+salsa20.c salsa20-meta.c \
 sha1.c sha1-compress.c sha1-meta.c \
 sha256.c sha256-compress.c sha224-meta.c sha256-meta.c \
 sha512.c sha512-compress.c sha384-meta.c sha512-meta.c \
@@ -113,7 +114,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
  pgp-encode.c rsa2openpgp.c \
  der-iterator.c der2rsa.c der2dsa.c
 
-HEADERS = aes.h arcfour.h arctwo.h asn1.h bignum.h blowfish.h \
+HEADERS = aes.h arcfour.h salsa20.h arctwo.h asn1.h bignum.h blowfish.h \
  base16.h base64.h buffer.h camellia.h cast128.h \
  cbc.h ctr.h gcm.h \
  des.h des-compat.h dsa.h \
diff --git a/examples/nettle-benchmark.c b/examples/nettle-benchmark.c
index 424ef19..44fca4e 100644
--- a/examples/nettle-benchmark.c
+++ b/examples/nettle-benchmark.c
@@ -40,6 +40,7 @@
 
 #include aes.h
 #include arcfour.h
+#include salsa20.h
 #include blowfish.h
 #include cast128.h
 #include cbc.h
@@ -612,6 +613,8 @@ main(int argc, char **argv)
   OPENSSL(nettle_openssl_aes192)
   OPENSSL(nettle_openssl_aes256)
   nettle_arcfour128, OPENSSL(nettle_openssl_arcfour128)
+  nettle_salsa20_128,
+  nettle_salsa20_256,
   nettle_blowfish128, OPENSSL(nettle_openssl_blowfish128)
   nettle_camellia128, nettle_camellia192, nettle_camellia256,
   nettle_cast128, OPENSSL(nettle_openssl_cast128)
diff --git a/nettle-meta-ciphers.c b/nettle-meta-ciphers.c
index 1f07595..aae90f9 100644
--- a/nettle-meta-ciphers.c
+++ b/nettle-meta-ciphers.c
@@ -36,6 +36,8 @@ const struct nettle_cipher

Re: Migration from CVS to GIT

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Martin Storsjö mar...@martin.st writes:

 The author mapping looks good to me at least, looking forward to the
 final repo

 Now final. Repo url git://git.lysator.liu.se/lsh/lsh.git. I renamed
 the old gitorious project to get the various test repositories out of
 the way.

Great!  I added it to my batch job to create statistics for, see output
here:

http://gitstats.josefsson.org/lsh/

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: Building libnettle on MS-Windows

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 With MinGW-64 I got the following error when building:

 For clarity: Is this MinGW-64 *natively* on a windows machine, or a
 cross compiler?

Cross-compiler, running on a Debian Squeeze machine.

 This seems to be the case when I build with --enable-shared as well --
 then there is only one hit (./.lib/libnettle-4-3.dll), but it is not
 under testsuite/. Should there be more *.dll files?

 For a native build: That's how it should be. The .lib directory is added
 to PATH, which should be sufficient for running the testprograms. The
 additional symlinks in the testsuite and example directories should be
 there only when cross compiling (detected by $EMULATOR matching wine*).

I have the binfmt-support package installed, so an emulator is not
strictly required -- i.e., running ./foo.exe will work directly and
using 'wine ./foo.exe' is not necessary.  Will $EMULATOR be empty in
this case?

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: gcm crash on ppc

[Simon Josefsson]

ni...@lysator.liu.se (Niels Möller) writes:

 Simon Josefsson si...@josefsson.org writes:

 What is fishy is that nettle_gcm_aes128 doesn't seem to have been
 initialized properly:

 Did you solve this problem? To me it seems like it could be

 * setup of the shared-library magic, for this particular object file,
   somehow broken.

 * bugs in the macos port of gcc (I don't know if you use apples xcode
   or some other gcc port, and I don't really know the difference
   either). According to the gmp people, there have been *lots* of
   problems with apple's linker and maybe also with other related tools.

 * some other random hardware or software problem.

The problem still occurs, but I'd be inclined to write it off as a
compiler bug because the system is running pretty old software (even if
it is latest published from Apple for this hardware).

espresso:~ jas$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

espresso:~ jas$ 

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: serpent again

[Simon Josefsson]

Btw, I have tested it on a core i7 (little endien) and a PPC machine
(big endian) and it worked.

(However, the 'gcm' self test crashed on PPC.)

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: making algorithms in nettle dynamically enumerable

[Simon Josefsson]

One comment is that it is more difficult to export variables portably
than functions (especially Windows), so sometimes it is preferred to
export a function that returns a static array than exporting the static
array itself.  However, I think nettle already relies on exporting
variables so then this point is moot.  I support the patch otherwise.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: nettle perl bindings

[Simon Josefsson]

Daniel Kahn Gillmor d...@fifthhorseman.net writes:

 Hi Nettle Folks--

 I'm building Perl bindings for libnettle.  I hope to claim the
 Crypt::Nettle namespace.

 The project is in its infancy, but i currently have coverage for all
 hash functions and ciphers.

 My next steps are adding bindings for Yarrow and RSA.

Don't forget to add RSA blinding, otherwise it may be vulnerable in the
real world.  I wish Nettle supported this natively, RSA is not generally
safe without it.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: nettle perl bindings

[Simon Josefsson]

Daniel Kahn Gillmor d...@fifthhorseman.net writes:

 Hi Simon--

 On 03/17/2011 04:45 AM, Simon Josefsson wrote:
 Don't forget to add RSA blinding, otherwise it may be vulnerable in the
 real world.  I wish Nettle supported this natively, RSA is not generally
 safe without it.

 Thanks for this suggestion -- i'm not sure that the perl bindings are
 the right place to do this, though.  Do other Nettle language bindings
 handle RSA blinding?  I'd rather have the perl bindings stay fairly
 close to the underlying C library.

Yes -- I agree.

Btw, thanks for working on perl bindings, that sounds really useful.

ni...@lysator.liu.se (Niels Möller) writes:

 It would make sense to add an RSA interface which takes a randomness
 source as input (for blinding), and a DSA interface which doesn't need a
 randomness source (and instead uses something like the hash of the
 message beeing signed as the random value needed, like it's done
 putty).

Yes, an interface like that seems like a simple and sufficient solution
to the problem.

/Simon
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs