- nettle-bugs - lists.lysator.liu.se

[PATCH] Add CFB block mode support
by Dmitry Eremin-Solenikov 25 Sep '17

25 Sep '17

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> --- Makefile.in | 4 +- cfb.c | 176 +++++++++++++++++++++++++++ cfb.h | 87 ++++++++++++++ nettle.texinfo | 106 +++++++++++++++-- testsuite/.gitignore | 1 + testsuite/.test-rules.make | 3 + testsuite/Makefile.in | 2 +- testsuite/cfb-test.c | 287 +++++++++++++++++++++++++++++++++++++++++++++ testsuite/testutils.c | 179 ++++++++++++++++++++++++++++ testsuite/testutils.h | 7 ++ 10 files changed, 840 insertions(+), 12 deletions(-) create mode 100644 cfb.c create mode 100644 cfb.h create mode 100644 testsuite/cfb-test.c diff --git a/Makefile.in b/Makefile.in index 7e8f29c2b3aa..9371f20f3d1c 100644 --- a/Makefile.in +++ b/Makefile.in @@ -91,7 +91,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \ camellia256-set-decrypt-key.c \ camellia256-meta.c \ cast128.c cast128-meta.c cbc.c \ - ccm.c ccm-aes128.c ccm-aes192.c ccm-aes256.c \ + ccm.c ccm-aes128.c ccm-aes192.c ccm-aes256.c cfb.c \ chacha-crypt.c chacha-core-internal.c \ chacha-poly1305.c chacha-poly1305-meta.c \ chacha-set-key.c chacha-set-nonce.c \ @@ -188,7 +188,7 @@ OPT_SOURCES = fat-x86_64.c fat-arm.c mini-gmp.c HEADERS = aes.h arcfour.h arctwo.h asn1.h blowfish.h \ base16.h base64.h bignum.h buffer.h camellia.h cast128.h \ - cbc.h ccm.h chacha.h chacha-poly1305.h ctr.h \ + cbc.h ccm.h cfb.h chacha.h chacha-poly1305.h ctr.h \ curve25519.h des.h des-compat.h dsa.h dsa-compat.h eax.h \ ecc-curve.h ecc.h ecdsa.h eddsa.h \ gcm.h gosthash94.h hmac.h \ diff --git a/cfb.c b/cfb.c new file mode 100644 index 000000000000..705568e73ecc --- /dev/null +++ b/cfb.c @@ -0,0 +1,176 @@ +/* cfb.c + + Cipher feedback mode. + + Copyright (C) 2015 Dmitry Eremin-Solenikov + Copyright (C) 2001, 2011 Niels Möller + + 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 <assert.h> +#include <stdlib.h> +#include <string.h> + +#include "cfb.h" + +#include "memxor.h" +#include "nettle-internal.h" + +void +cfb_encrypt(const void *ctx, nettle_cipher_func *f, + size_t block_size, uint8_t *iv, + size_t length, uint8_t *dst, + const uint8_t *src) +{ + if (src != dst) + { + uint8_t *p; + + for (p = iv; length >= block_size; p = dst, dst += block_size, src += block_size, length -= block_size) + { + f(ctx, block_size, dst, p); + memxor(dst, src, block_size); + } + + if (p != iv) + memcpy(iv, p, block_size); + + if (length) + { + TMP_DECL(buffer, uint8_t, NETTLE_MAX_CIPHER_BLOCK_SIZE); + TMP_ALLOC(buffer, block_size); + + f(ctx, block_size, buffer, iv); + memxor3(dst, buffer, src, length); + memcpy(iv, dst, length); + } + } + else + { + TMP_DECL(buffer, uint8_t, NETTLE_MAX_CIPHER_BLOCK_SIZE); + TMP_ALLOC(buffer, block_size); + uint8_t *p; + + for (p = iv; length >= block_size; p = dst, dst += block_size, length -= block_size) + { + f(ctx, block_size, buffer, p); + memxor(dst, buffer, block_size); + } + + if (p != iv) + memcpy(iv, p, block_size); + + if (length) + { + f(ctx, block_size, buffer, iv); + memxor(dst, buffer, length); + memcpy(iv, dst, length); + } + } +} + +/* Don't allocate any more space than this on the stack */ +#define CFB_BUFFER_LIMIT 512 + +void +cfb_decrypt(const void *ctx, nettle_cipher_func *f, + size_t block_size, uint8_t *iv, + size_t length, uint8_t *dst, + const uint8_t *src) +{ + if (!length) + return; + + if (src != dst) + { + size_t left = length % block_size; + + length -= left; + if (length >= block_size) + { + /* Decrypt in ECB mode */ + f(ctx, block_size, dst, iv); + f(ctx, length - block_size, dst + block_size, src); + memxor(dst, src, length); + memcpy(iv, src + length - block_size, block_size); + } + + if (left > 0) + { + TMP_DECL(buffer, uint8_t, NETTLE_MAX_CIPHER_BLOCK_SIZE); + TMP_ALLOC(buffer, block_size); + + f(ctx, block_size, buffer, iv); + memxor3(dst + length, src + length, buffer, left); + memcpy(iv, src + length, left); + } + } + else + { + /* For in-place CFB, we decrypt into a temporary buffer of size + * at most CFB_BUFFER_LIMIT, and process that amount of data at + * a time. */ + + /* NOTE: We assume that block_size <= CFB_BUFFER_LIMIT */ + + TMP_DECL(buffer, uint8_t, CFB_BUFFER_LIMIT); + TMP_DECL(initial_iv, uint8_t, NETTLE_MAX_CIPHER_BLOCK_SIZE); + + size_t buffer_size; + size_t left; + + buffer_size = CFB_BUFFER_LIMIT - (CFB_BUFFER_LIMIT % block_size); + + TMP_ALLOC(buffer, buffer_size); + TMP_ALLOC(initial_iv, block_size); + + for ( ; length >= buffer_size; + length -= buffer_size, src += buffer_size, dst += buffer_size) + { + f(ctx, block_size, buffer, iv); + f(ctx, buffer_size - block_size, buffer + block_size, src); + memcpy(iv, src + buffer_size - block_size, block_size); + memxor3(dst, buffer, src, buffer_size); + } + + if (length % block_size) + left = length % block_size; + else + left = block_size; + f(ctx, block_size, buffer, iv); + f(ctx, length - left, buffer + block_size, src); + memcpy(iv, src + length - left, left); + if (length - left >= block_size) + memcpy(iv + left, src + length - left - block_size, block_size - left); + memxor3(dst, buffer, src, length); + } +} diff --git a/cfb.h b/cfb.h new file mode 100644 index 000000000000..76134eeb41a0 --- /dev/null +++ b/cfb.h @@ -0,0 +1,87 @@ +/* cfb.h + + Cipher feedback mode. + + Copyright (C) 2015 Dmitry Eremin-Solenikov + Copyright (C) 2001 Niels Möller + + 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/. +*/ + +#ifndef NETTLE_CFB_H_INCLUDED +#define NETTLE_CFB_H_INCLUDED + +#include "nettle-types.h" + +#ifdef __cplusplus +extern "C" { +#endif + +/* Name mangling */ +#define cfb_encrypt nettle_cfb_encrypt +#define cfb_decrypt nettle_cfb_decrypt + +void +cfb_encrypt(const void *ctx, nettle_cipher_func *f, + size_t block_size, uint8_t *iv, + size_t length, uint8_t *dst, + const uint8_t *src); + +void +cfb_decrypt(const void *ctx, nettle_cipher_func *f, + size_t block_size, uint8_t *iv, + size_t length, uint8_t *dst, + const uint8_t *src); + +#define CFB_CTX(type, size) \ +{ type ctx; uint8_t iv[size]; } + +#define CFB_SET_IV(ctx, data) \ +memcpy((ctx)->iv, (data), sizeof((ctx)->iv)) + +/* NOTE: Avoid using NULL, as we don't include anything defining it. */ +#define CFB_ENCRYPT(self, f, length, dst, src) \ + (0 ? ((f)(&(self)->ctx, ~(size_t) 0, \ + (uint8_t *) 0, (const uint8_t *) 0)) \ + : cfb_encrypt((void *) &(self)->ctx, \ + (nettle_cipher_func *) (f), \ + sizeof((self)->iv), (self)->iv, \ + (length), (dst), (src))) + +#define CFB_DECRYPT(self, f, length, dst, src) \ + (0 ? ((f)(&(self)->ctx, ~(size_t) 0, \ + (uint8_t *) 0, (const uint8_t *) 0)) \ + : cfb_decrypt((void *) &(self)->ctx, \ + (nettle_cipher_func *) (f), \ + sizeof((self)->iv), (self)->iv, \ + (length), (dst), (src))) + +#ifdef __cplusplus +} +#endif + +#endif /* NETTLE_CFB_H_INCLUDED */ diff --git a/nettle.texinfo b/nettle.texinfo index 1d7e4e3e7f6b..9b017a7ffcf1 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -93,6 +93,7 @@ Cipher modes * CBC:: * CTR:: +* CFB:: * GCM:: * CCM:: @@ -1884,21 +1885,23 @@ a message that is larger than the cipher's block size. As explained in processing them independently with the block cipher (Electronic Code Book mode, @acronym{ECB}), leaks information. -Besides @acronym{ECB}, Nettle provides a two other modes of operation: -Cipher Block Chaining (@acronym{CBC}), Counter mode (@acronym{CTR}), and -a couple of @acronym{AEAD} modes (@pxref{Authenticated encryption}). -@acronym{CBC} is widely used, but there are a few subtle issues of -information leakage, see, e.g., +Besides @acronym{ECB}, Nettle provides several other modes of operation: +Cipher Block Chaining (@acronym{CBC}), Counter mode (@acronym{CTR}), Cipher +Feedback (@acronym{CFB}) and a couple of @acronym{AEAD} modes +(@pxref{Authenticated encryption}). @acronym{CBC} is widely used, but +there are a few subtle issues of information leakage, see, e.g., @uref{http://www.kb.cert.org/vuls/id/958563, @acronym{SSH} @acronym{CBC} vulnerability}. Today, @acronym{CTR} is usually preferred over @acronym{CBC}. -Modes like @acronym{CBC} and @acronym{CTR} provide @emph{no} message -authentication, and should always be used together with a @acronym{MAC} -(@pxref{Keyed hash functions}) or signature to authenticate the message. +Modes like @acronym{CBC}, @acronym{CTR} and @acronym{CFB} provide @emph{no} +message authentication, and should always be used together with a +@acronym{MAC} (@pxref{Keyed hash functions}) or signature to authenticate +the message. @menu * CBC:: * CTR:: +* CFB:: @end menu @node CBC, CTR, Cipher modes, Cipher modes @@ -1994,7 +1997,7 @@ These macros use some tricks to make the compiler display a warning if the types of @var{f} and @var{ctx} don't match, e.g. if you try to use an @code{struct aes_ctx} context with the @code{des_encrypt} function. -@node CTR, , CBC, Cipher modes +@node CTR, CFB, CBC, Cipher modes @comment node-name, next, previous, up @subsection Counter mode @@ -2070,6 +2073,91 @@ last three arguments define the source and destination area for the operation. @end deffn +@node CFB, , CTR, Cipher modes +@comment node-name, next, previous, up +@subsection Cipher Feedback mode + +@cindex Cipher Feedback Mode +@cindex CFB Mode + +Cipher Feedback mode (@acronym{CFB}) being a close relative to both +@acronym{CBC} mode and @acronym{CTR} mode transforms block cipher into a +stream cipher. + +The message is divided into @code{n} blocks @code{M_1},@dots{} +@code{M_n}, where @code{M_n} is of size @code{m} which may be smaller +than the block size. Except for the last block, all the message blocks +must be of size equal to the cipher's block size. + +If @code{E_k} is the encryption function of a block cipher, @code{IV} is +the initialization vector, then the @code{n} plaintext blocks are +transformed into @code{n} ciphertext blocks @code{C_1},@dots{} +@code{C_n} as follows: + +@example +C_1 = E_k(IV) XOR M_1 +C_2 = E_k(C_1) XOR M_2 + +@dots{} + +C_(n-1) = E_k(C_(n - 2)) XOR M_(n-1) +C_n = E_k(C_(n - 1)) [1..m] XOR M_n +@end example + +Nettle's includes two functions for applying a block cipher in Cipher +Feedback Mode (@acronym{CFB}) mode, one for encryption and one for +decryption. These functions uses @code{void *} to pass cipher contexts +around. + +@deftypefun {void} cbc_encrypt (const void *@var{ctx}, nettle_cipher_func *@var{f}, size_t @var{block_size}, uint8_t *@var{iv}, size_t @var{length}, uint8_t *@var{dst}, const uint8_t *@var{src}) +@deftypefunx {void} cbc_decrypt (const void *@var{ctx}, nettle_cipher_func *@var{f}, size_t @var{block_size}, uint8_t *@var{iv}, size_t @var{length}, uint8_t *@var{dst}, const uint8_t *@var{src}) + +Applies the encryption or decryption function @var{f} in @acronym{CBC} +mode. The final ciphertext block processed is copied into @var{iv} +before returning, so that a large message can be processed by a sequence of +calls to @code{cfb_encrypt}. Note that for @acronym{CFB} mode internally +uses encryption only function and hence @var{f} should always be the +encryption function for the underlying block cipher. + +When a message is encrypted using a sequence of calls to +@code{cfb_encrypt}, all but the last call @emph{must} use a length that is +a multiple of the block size. +@end deftypefun + +Like for @acronym{CFB}, there are also a couple of helper macros. + +@deffn Macro CFB_CTX (@var{context_type}, @var{block_size}) +Expands to +@example +@{ + context_type ctx; + uint8_t iv[block_size]; +@} +@end example +@end deffn + +@deffn Macro CFB_SET_IV(@var{ctx}, @var{iv}) +First argument is a pointer to a context struct as defined by +@code{CFB_CTX}, and the second is a pointer to an initialization vector +that is copied into that context. +@end deffn + +@deffn Macro CFB_ENCRYPT (@var{ctx}, @var{f}, @var{length}, @var{dst}, @var{src}) +A simpler way to invoke @code{cfb_encrypt}. The first argument is a +pointer to a context struct as defined by @code{CFB_CTX}, and the second +argument is an encryption function following Nettle's conventions. The +last three arguments define the source and destination area for the +operation. +@end deffn + +@deffn Macro CFB_DECRYPT (@var{ctx}, @var{f}, @var{length}, @var{dst}, @var{src}) +A simpler way to invoke @code{cfb_decrypt}. The first argument is a +pointer to a context struct as defined by @code{CFB_CTX}, and the second +argument is an encryption function following Nettle's conventions. The +last three arguments define the source and destination area for the +operation. +@end deffn + @node Authenticated encryption, Keyed hash functions, Cipher modes, Reference @comment node-name, next, previous, up diff --git a/testsuite/.gitignore b/testsuite/.gitignore index a50bc44c8fcd..8558b7f3b02f 100644 --- a/testsuite/.gitignore +++ b/testsuite/.gitignore @@ -12,6 +12,7 @@ /cast128-test /cbc-test /ccm-test +/cfb-test /chacha-poly1305-test /chacha-test /ctr-test diff --git a/testsuite/.test-rules.make b/testsuite/.test-rules.make index 1b9c3faea279..7bc0d3381c87 100644 --- a/testsuite/.test-rules.make +++ b/testsuite/.test-rules.make @@ -112,6 +112,9 @@ knuth-lfib-test$(EXEEXT): knuth-lfib-test.$(OBJEXT) cbc-test$(EXEEXT): cbc-test.$(OBJEXT) $(LINK) cbc-test.$(OBJEXT) $(TEST_OBJS) -o cbc-test$(EXEEXT) +cfb-test$(EXEEXT): cfb-test.$(OBJEXT) + $(LINK) cfb-test.$(OBJEXT) $(TEST_OBJS) -o cfb-test$(EXEEXT) + ctr-test$(EXEEXT): ctr-test.$(OBJEXT) $(LINK) ctr-test.$(OBJEXT) $(TEST_OBJS) -o ctr-test$(EXEEXT) diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in index c1ac7d241f7f..4d90bffd1f54 100644 --- a/testsuite/Makefile.in +++ b/testsuite/Makefile.in @@ -25,7 +25,7 @@ TS_NETTLE_SOURCES = aes-test.c arcfour-test.c arctwo-test.c \ sha3-384-test.c sha3-512-test.c \ serpent-test.c twofish-test.c version-test.c \ knuth-lfib-test.c \ - cbc-test.c ctr-test.c gcm-test.c eax-test.c ccm-test.c \ + cbc-test.c cfb-test.c ctr-test.c gcm-test.c eax-test.c ccm-test.c \ poly1305-test.c chacha-poly1305-test.c \ hmac-test.c umac-test.c \ meta-hash-test.c meta-cipher-test.c\ diff --git a/testsuite/cfb-test.c b/testsuite/cfb-test.c new file mode 100644 index 000000000000..37f0201f2e3d --- /dev/null +++ b/testsuite/cfb-test.c @@ -0,0 +1,287 @@ +#include "testutils.h" +#include "aes.h" +#include "cfb.h" +#include "knuth-lfib.h" + +/* Test with more data and inplace decryption, to check that the + * cfb_decrypt buffering works. */ +#define CFB_BULK_DATA 0x2710 /* 10000 */ + +static void +test_cfb_bulk(void) +{ + struct knuth_lfib_ctx random; + + uint8_t clear[CFB_BULK_DATA]; + + uint8_t cipher[CFB_BULK_DATA + 1]; + + const uint8_t *key = H("966c7bf00bebe6dc 8abd37912384958a" + "743008105a08657d dcaad4128eee38b3"); + + const uint8_t *start_iv = H("11adbff119749103 207619cfa0e8d13a"); + const uint8_t *end_iv = H("1fd0a9189b8480b7 b06a2b36ef5943ba"); + + struct CFB_CTX(struct aes_ctx, AES_BLOCK_SIZE) aes; + + knuth_lfib_init(&random, CFB_BULK_DATA); + knuth_lfib_random(&random, CFB_BULK_DATA, clear); + + /* Byte that should not be overwritten */ + cipher[CFB_BULK_DATA] = 17; + + aes_set_encrypt_key(&aes.ctx, 32, key); + CFB_SET_IV(&aes, start_iv); + + CFB_ENCRYPT(&aes, aes_encrypt, CFB_BULK_DATA, cipher, clear); + + ASSERT(cipher[CFB_BULK_DATA] == 17); + + if (verbose) + { + printf("IV after bulk encryption: "); + print_hex(AES_BLOCK_SIZE, aes.iv); + printf("\n"); + } + + ASSERT(MEMEQ(AES_BLOCK_SIZE, aes.iv, end_iv)); + + /* Decrypt, in place */ + aes_set_encrypt_key(&aes.ctx, 32, key); + CFB_SET_IV(&aes, start_iv); + CFB_DECRYPT(&aes, aes_encrypt, CFB_BULK_DATA, cipher, cipher); + + ASSERT(cipher[CFB_BULK_DATA] == 17); + + if (verbose) + { + printf("IV after bulk decryption: "); + print_hex(AES_BLOCK_SIZE, aes.iv); + printf("\n"); + } + + ASSERT (MEMEQ(AES_BLOCK_SIZE, aes.iv, end_iv)); + ASSERT (MEMEQ(CFB_BULK_DATA, clear, cipher)); +} + +void +test_main(void) +{ + /* From NIST spec 800-38a on AES modes. + * + * F.3 CFB Example Vectors + * F.3.13 CFB128-AES128.Encrypt + */ + + /* Intermediate values, blocks input to AES: + * + * 000102030405060708090a0b0c0d0e0f + * 3b3fd92eb72dad20333449f8e83cfb4a + * c8a64537a0b3a93fcde3cdad9f1ce58b + * 26751f67a3cbb140b1808cf187a4f4df + */ + test_cipher_cfb(&nettle_aes128, + SHEX("2b7e151628aed2a6abf7158809cf4f3c"), + SHEX("6bc1bee22e409f96e93d7e117393172a" + "ae2d8a571e03ac9c9eb76fac45af8e51" + "30c81c46a35ce411e5fbc1191a0a52ef" + "f69f2445df4f9b17ad2b417be66c3710"), + SHEX("3b3fd92eb72dad20333449f8e83cfb4a" + "c8a64537a0b3a93fcde3cdad9f1ce58b" + "26751f67a3cbb140b1808cf187a4f4df" + "c04b05357c5d1c0eeac4c66f9ff7f2e6"), + SHEX("000102030405060708090a0b0c0d0e0f")); + + /* F.2.3 CFB128-AES192.Encrypt */ + + /* Intermediate values, blocks input to AES: + * + * 000102030405060708090a0b0c0d0e0f + * cdc80d6fddf18cab34c25909c99a4174 + * 67ce7f7f81173621961a2b70171d3d7a + * 2e1e8a1dd59b88b1c8e60fed1efac4c9 + */ + + test_cipher_cfb(&nettle_aes192, + SHEX("8e73b0f7da0e6452c810f32b809079e5" + "62f8ead2522c6b7b"), + SHEX("6bc1bee22e409f96e93d7e117393172a" + "ae2d8a571e03ac9c9eb76fac45af8e51" + "30c81c46a35ce411e5fbc1191a0a52ef" + "f69f2445df4f9b17ad2b417be66c3710"), + SHEX("cdc80d6fddf18cab34c25909c99a4174" + "67ce7f7f81173621961a2b70171d3d7a" + "2e1e8a1dd59b88b1c8e60fed1efac4c9" + "c05f9f9ca9834fa042ae8fba584b09ff"), + SHEX("000102030405060708090a0b0c0d0e0f")); + + /* F.2.5 CFB128-AES256.Encrypt */ + + /* Intermediate values, blcoks input to AES: + * + * 000102030405060708090a0b0c0d0e0f + * dc7e84bfda79164b7ecd8486985d3860 + * 39ffed143b28b1c832113c6331e5407b + * df10132415e54b92a13ed0a8267ae2f9 + */ + + test_cipher_cfb(&nettle_aes256, + SHEX("603deb1015ca71be2b73aef0857d7781" + "1f352c073b6108d72d9810a30914dff4"), + SHEX("6bc1bee22e409f96e93d7e117393172a" + "ae2d8a571e03ac9c9eb76fac45af8e51" + "30c81c46a35ce411e5fbc1191a0a52ef" + "f69f2445df4f9b17ad2b417be66c3710"), + SHEX("dc7e84bfda79164b7ecd8486985d3860" + "39ffed143b28b1c832113c6331e5407b" + "df10132415e54b92a13ed0a8267ae2f9" + "75a385741ab9cef82031623d55b1e471"), + SHEX("000102030405060708090a0b0c0d0e0f")); + + test_cfb_bulk(); +} + +/* +F.3.13 CFB128-AES128.Encrypt +Key 2b7e151628aed2a6abf7158809cf4f3c +IV 000102030405060708090a0b0c0d0e0f +Segment #1 +Input Block 000102030405060708090a0b0c0d0e0f +Output Block 50fe67cc996d32b6da0937e99bafec60 +Plaintext 6bc1bee22e409f96e93d7e117393172a +Ciphertext 3b3fd92eb72dad20333449f8e83cfb4a +Segment #2 +Input Block 3b3fd92eb72dad20333449f8e83cfb4a +Output Block 668bcf60beb005a35354a201dab36bda +Plaintext ae2d8a571e03ac9c9eb76fac45af8e51 +Ciphertext c8a64537a0b3a93fcde3cdad9f1ce58b +Segment #3 +Input Block c8a64537a0b3a93fcde3cdad9f1ce58b +Output Block 16bd032100975551547b4de89daea630 +Plaintext 30c81c46a35ce411e5fbc1191a0a52ef +Ciphertext 26751f67a3cbb140b1808cf187a4f4df +Segment #4 +Input Block 26751f67a3cbb140b1808cf187a4f4df +Output Block 36d42170a312871947ef8714799bc5f6 +Plaintext f69f2445df4f9b17ad2b417be66c3710 +Ciphertext c04b05357c5d1c0eeac4c66f9ff7f2e6 +F.3.14 CFB128-AES128.Decrypt +Key 2b7e151628aed2a6abf7158809cf4f3c +IV 000102030405060708090a0b0c0d0e0f +Segment #1 +Input Block 000102030405060708090a0b0c0d0e0f +Output Block 50fe67cc996d32b6da0937e99bafec60 +Ciphertext 3b3fd92eb72dad20333449f8e83cfb4a +Plaintext 6bc1bee22e409f96e93d7e117393172a +Segment #2 +Input Block 3b3fd92eb72dad20333449f8e83cfb4a +Output Block 668bcf60beb005a35354a201dab36bda +Ciphertext c8a64537a0b3a93fcde3cdad9f1ce58b +Plaintext ae2d8a571e03ac9c9eb76fac45af8e51 +Segment #3 +Input Block c8a64537a0b3a93fcde3cdad9f1ce58b +Output Block 16bd032100975551547b4de89daea630 +Ciphertext 26751f67a3cbb140b1808cf187a4f4df +Plaintext 30c81c46a35ce411e5fbc1191a0a52ef +Segment #4 +Input Block 26751f67a3cbb140b1808cf187a4f4df +Output Block 36d42170a312871947ef8714799bc5f6 +Ciphertext c04b05357c5d1c0eeac4c66f9ff7f2e6 +Plaintext f69f2445df4f9b17ad2b417be66c3710 +F.3.15 CFB128-AES192.Encrypt +Key 8e73b0f7da0e6452c810f32b809079e562f8ead2522c6b7b +000102030405060708090a0b0c0d0e0f +Segment #1 +50 +IV +Input Block 000102030405060708090a0b0c0d0e0f +Output Block a609b38df3b1133dddff2718ba09565e +Plaintext 6bc1bee22e409f96e93d7e117393172a +Ciphertext cdc80d6fddf18cab34c25909c99a4174 +Segment #2 +Input Block cdc80d6fddf18cab34c25909c99a4174 +Output Block c9e3f5289f149abd08ad44dc52b2b32b +Plaintext ae2d8a571e03ac9c9eb76fac45af8e51 +Ciphertext 67ce7f7f81173621961a2b70171d3d7a +Segment #3 +Input Block 67ce7f7f81173621961a2b70171d3d7a +Output Block 1ed6965b76c76ca02d1dcef404f09626 +Plaintext 30c81c46a35ce411e5fbc1191a0a52ef +Ciphertext 2e1e8a1dd59b88b1c8e60fed1efac4c9 +Segment #4 +Input Block 2e1e8a1dd59b88b1c8e60fed1efac4c9 +Output Block 36c0bbd976ccd4b7ef85cec1be273eef +Plaintext f69f2445df4f9b17ad2b417be66c3710 +Ciphertext c05f9f9ca9834fa042ae8fba584b09ff +F.3.16 CFB128-AES192.Decrypt +Key 8e73b0f7da0e6452c810f32b809079e562f8ead2522c6b7b +IV 000102030405060708090a0b0c0d0e0f +Segment #1 +Input Block 000102030405060708090a0b0c0d0e0f +Output Block a609b38df3b1133dddff2718ba09565e +Ciphertext cdc80d6fddf18cab34c25909c99a4174 +Plaintext 6bc1bee22e409f96e93d7e117393172a +Segment #2 +Input Block cdc80d6fddf18cab34c25909c99a4174 +Output Block c9e3f5289f149abd08ad44dc52b2b32b +Ciphertext 67ce7f7f81173621961a2b70171d3d7a +Plaintext ae2d8a571e03ac9c9eb76fac45af8e51 +Segment #3 +Input Block 67ce7f7f81173621961a2b70171d3d7a +Output Block 1ed6965b76c76ca02d1dcef404f09626 +Ciphertext 2e1e8a1dd59b88b1c8e60fed1efac4c9 +Plaintext 30c81c46a35ce411e5fbc1191a0a52ef +Segment #4 +Input Block 2e1e8a1dd59b88b1c8e60fed1efac4c9 +Output Block 36c0bbd976ccd4b7ef85cec1be273eef +Ciphertext c05f9f9ca9834fa042ae8fba584b09ff +Plaintext f69f2445df4f9b17ad2b417be66c3710 +F.3.17 CFB128-AES256.Encrypt +Key 603deb1015ca71be2b73aef0857d7781 +1f352c073b6108d72d9810a30914dff4 +IV 000102030405060708090a0b0c0d0e0f +Segment #1 +Input Block 000102030405060708090a0b0c0d0e0f +Output Block b7bf3a5df43989dd97f0fa97ebce2f4a +Plaintext 6bc1bee22e409f96e93d7e117393172a +Ciphertext dc7e84bfda79164b7ecd8486985d3860 +Segment #2 +Input Block dc7e84bfda79164b7ecd8486985d3860 +Output Block 97d26743252b1d54aca653cf744ace2a +Plaintext ae2d8a571e03ac9c9eb76fac45af8e51 +Ciphertext 39ffed143b28b1c832113c6331e5407b +Segment #3 +Input Block 39ffed143b28b1c832113c6331e5407b +Output Block efd80f62b6b9af8344c511b13c70b016 +Plaintext 30c81c46a35ce411e5fbc1191a0a52ef +Ciphertext df10132415e54b92a13ed0a8267ae2f9 +Segment #4 +Input Block df10132415e54b92a13ed0a8267ae2f9 +Output Block 833ca131c5f655ef8d1a2346b3ddd361 +Plaintext f69f2445df4f9b17ad2b417be66c3710 +Ciphertext 75a385741ab9cef82031623d55b1e471 +F.3.18 CFB128-AES256.Decrypt +Key 603deb1015ca71be2b73aef0857d7781 +1f352c073b6108d72d9810a30914dff4 +IV 000102030405060708090a0b0c0d0e0f +Segment #1 +Input Block 000102030405060708090a0b0c0d0e0f +Output Block b7bf3a5df43989dd97f0fa97ebce2f4a +Ciphertext dc7e84bfda79164b7ecd8486985d3860 +Plaintext 6bc1bee22e409f96e93d7e117393172a +Segment #2 +Input Block dc7e84bfda79164b7ecd8486985d3860 +Output Block 97d26743252b1d54aca653cf744ace2a +Ciphertext 39ffed143b28b1c832113c6331e5407b +Plaintext ae2d8a571e03ac9c9eb76fac45af8e51 +Segment #3 +Input Block 39ffed143b28b1c832113c6331e5407b +Output Block efd80f62b6b9af8344c511b13c70b016 +Ciphertext df10132415e54b92a13ed0a8267ae2f9 +Plaintext 30c81c46a35ce411e5fbc1191a0a52ef +Segment #4 +Input Block df10132415e54b92a13ed0a8267ae2f9 +Output Block 833ca131c5f655ef8d1a2346b3ddd361 +Ciphertext 75a385741ab9cef82031623d55b1e471 +Plaintext f69f2445df4f9b17ad2b417be66c3710 +*/ diff --git a/testsuite/testutils.c b/testsuite/testutils.c index 55aa5e8150e6..d2122eb765cf 100644 --- a/testsuite/testutils.c +++ b/testsuite/testutils.c @@ -4,6 +4,7 @@ #include "base16.h" #include "cbc.h" +#include "cfb.h" #include "ctr.h" #include "knuth-lfib.h" #include "macros.h" @@ -244,6 +245,184 @@ test_cipher_cbc(const struct nettle_cipher *cipher, free(iv); } +void +test_cipher_cfb(const struct nettle_cipher *cipher, + const struct tstring *key, + const struct tstring *cleartext, + const struct tstring *ciphertext, + const struct tstring *iiv) +{ + void *ctx = xalloc(cipher->context_size); + uint8_t *data, *data2; + uint8_t *iv = xalloc(cipher->block_size); + size_t length; + + ASSERT (cleartext->length == ciphertext->length); + length = cleartext->length; + + ASSERT (key->length == cipher->key_size); + ASSERT (iiv->length == cipher->block_size); + + data = xalloc(length); + data2 = xalloc(length); + + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + + cfb_encrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data, cleartext->data); + + if (!MEMEQ(length, data, ciphertext->data)) + { + fprintf(stderr, "CFB encrypt failed:\nInput:"); + tstring_print_hex(cleartext); + fprintf(stderr, "\nOutput: "); + print_hex(length, data); + fprintf(stderr, "\nExpected:"); + tstring_print_hex(ciphertext); + fprintf(stderr, "\n"); + FAIL(); + } + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + + cfb_decrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data2, data); + + if (!MEMEQ(length, data2, cleartext->data)) + { + fprintf(stderr, "CFB decrypt failed:\nInput:"); + tstring_print_hex(ciphertext); + fprintf(stderr, "\nOutput: "); + print_hex(length, data2); + fprintf(stderr, "\nExpected:"); + tstring_print_hex(cleartext); + fprintf(stderr, "\n"); + FAIL(); + } + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + memcpy(data, cleartext->data, length); + + cfb_encrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data, data); + + if (!MEMEQ(length, data, ciphertext->data)) + { + fprintf(stderr, "CFB inplace encrypt failed:\nInput:"); + tstring_print_hex(cleartext); + fprintf(stderr, "\nOutput: "); + print_hex(length, data); + fprintf(stderr, "\nExpected:"); + tstring_print_hex(ciphertext); + fprintf(stderr, "\n"); + FAIL(); + } + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + + cfb_decrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data, data); + + if (!MEMEQ(length, data, cleartext->data)) + { + fprintf(stderr, "CFB inplace decrypt failed:\nInput:"); + tstring_print_hex(ciphertext); + fprintf(stderr, "\nOutput: "); + print_hex(length, data); + fprintf(stderr, "\nExpected:"); + tstring_print_hex(cleartext); + fprintf(stderr, "\n"); + FAIL(); + } + + /* Repeat all tests with incomplete last block */ + length -= 1; + + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + + cfb_encrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data, cleartext->data); + + if (!MEMEQ(length, data, ciphertext->data)) + { + fprintf(stderr, "CFB encrypt failed:\nInput:"); + print_hex(length, cleartext->data); + fprintf(stderr, "\nOutput: "); + print_hex(length, data); + fprintf(stderr, "\nExpected:"); + print_hex(length, ciphertext->data); + fprintf(stderr, "\n"); + FAIL(); + } + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + + cfb_decrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data2, data); + + if (!MEMEQ(length, data2, cleartext->data)) + { + fprintf(stderr, "CFB decrypt failed:\nInput:"); + print_hex(length, ciphertext->data); + fprintf(stderr, "\nOutput: "); + print_hex(length, data2); + fprintf(stderr, "\nExpected:"); + print_hex(length, cleartext->data); + fprintf(stderr, "\n"); + FAIL(); + } + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + memcpy(data, cleartext->data, length); + + cfb_encrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data, data); + + if (!MEMEQ(length, data, ciphertext->data)) + { + fprintf(stderr, "CFB inplace encrypt failed:\nInput:"); + print_hex(length, cleartext->data); + fprintf(stderr, "\nOutput: "); + print_hex(length, data); + fprintf(stderr, "\nExpected:"); + print_hex(length, ciphertext->data); + fprintf(stderr, "\n"); + FAIL(); + } + cipher->set_encrypt_key(ctx, key->data); + memcpy(iv, iiv->data, cipher->block_size); + + cfb_decrypt(ctx, cipher->encrypt, + cipher->block_size, iv, + length, data, data); + + if (!MEMEQ(length, data, cleartext->data)) + { + fprintf(stderr, "CFB inplace decrypt failed:\nInput:"); + print_hex(length, ciphertext->data); + fprintf(stderr, "\nOutput: "); + print_hex(length, data); + fprintf(stderr, "\nExpected:"); + print_hex(length, cleartext->data); + fprintf(stderr, "\n"); + FAIL(); + } + + free(ctx); + free(data); + free(data2); + free(iv); +} + void test_cipher_ctr(const struct nettle_cipher *cipher, const struct tstring *key, diff --git a/testsuite/testutils.h b/testsuite/testutils.h index 7c44772b7748..0a05955771e4 100644 --- a/testsuite/testutils.h +++ b/testsuite/testutils.h @@ -122,6 +122,13 @@ test_cipher_cbc(const struct nettle_cipher *cipher, const struct tstring *ciphertext, const struct tstring *iv); +void +test_cipher_cfb(const struct nettle_cipher *cipher, + const struct tstring *key, + const struct tstring *cleartext, + const struct tstring *ciphertext, + const struct tstring *iv); + void test_cipher_ctr(const struct nettle_cipher *cipher, const struct tstring *key, -- 2.14.1

2 3

static analyzer results
by Nikos Mavrogiannopoulos 25 Sep '17

25 Sep '17

Hi, There are still two open issues with the static analyzer at [0]. Both are at ecc-mod(), where the hi value can be used uninitialized on two occasions; ecc-mod.c:104 and ecc-mod.c:110. The issue can be addressed by initializing to zero, but although it looks reasonable, I'm not sure if that's the expectation of the algorithm. Addressing that issue would allow for successful CI runs. regards, Nikos [0]. Build Job: https://gitlab.com/gnutls/nettle/-/jobs/31862567 Report: https://gitlab.com/gnutls/nettle/-/jobs/31862567/artifacts/browse/scan-buil…

4 13

Commit 57e304262262b0f483d76f9981bb4b99b8ec2869 breaks build
by Tim Rühsen 12 Sep '17

12 Sep '17

Hi, commit 57e304262262b0f483d76f9981bb4b99b8ec2869 breaks certain builds (likely those with --disable-shared). As a side effect, the oss-fuzz build for Wget2 fails. Example: ./.bootstrap ./configure --enable-mini-gmp --enable-static --disable-shared --disable-documentation make clean && make ... make[1]: Entering directory '/usr/oms/src/nettle/testsuite' gcc -I.. -I.. -DHAVE_CONFIG_H -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT sha1-huge-test.o -MD -MP -MF sha1-huge-test.o.d -c sha1-huge-test.c && true gcc -I.. -I.. -DHAVE_CONFIG_H -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT testutils.o -MD -MP -MF testutils.o.d -c testutils.c && true In file included from testutils.c:3:0: testutils.c: In function ‘tstring_hex’: testutils.c:82:13: warning: pointer targets in passing argument 5 of ‘nettle_base16_decode_update’ differ in signedness [-Wpointer-sign] length, hex)); ^ testutils.h:293:11: note: in definition of macro ‘ASSERT’ if (!(x)) \ ^ In file included from testutils.c:5:0: ../base16.h:49:30: note: expected ‘const uint8_t * {aka const unsigned char *}’ but argument is of type ‘const char *’ #define base16_decode_update nettle_base16_decode_update ^ ../base16.h:96:1: note: in expansion of macro ‘base16_decode_update’ base16_decode_update(struct base16_decode_ctx *ctx, ^~~~~~~~~~~~~~~~~~~~ gcc -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L.. sha1-huge-test.o testutils.o ../nettle-internal.o -lhogweed -lnettle -o sha1-huge-test ../libhogweed.a(mini-gmp.o): In function `mpn_zero_p': /usr/oms/src/nettle/mini-gmp.c:391: multiple definition of `mpn_zero_p' testutils.o:/usr/oms/src/nettle/testsuite/testutils.c:612: first defined here collect2: error: ld returned 1 exit status .test-rules.make:263: recipe for target 'sha1-huge-test' failed make[1]: *** [sha1-huge-test] Error 1 make[1]: Leaving directory '/usr/oms/src/nettle/testsuite' Makefile:49: recipe for target 'all' failed make: *** [all] Error 2 Regards, Tim

2 1

TLS PRF + HKDF
by Nikos Mavrogiannopoulos 07 Sep '17

07 Sep '17

Hi, The attached patch set introduces new APIs to access the TLS 1.0 and 1.2 PRFs as well as the HKDF (rfc5869) function used in TLS 1.3. There are few other updates to .gitlab-ci.yml (to use a more recent asan and ubsan versions), and a comment in .bootstrap for the testsuite/.test-rules.make which I always seem to forget and spend an hour figuring out what is going on. Ideally .test-rules.make should depend on Makefile.in so that one wouldn't need to manually run test- rules. I'd also suggest to rename the .bootstrap to bootstrap.sh as the latter is quite a convention to find in projects (.bootstrap is not even listed in ls). regards, Nikos

4 26

[PATCH] Fix fat-arm build with glibc
by Andreas Schneider 06 Sep '17

06 Sep '17

Hi, the attached patch fixes the ARM build. We need to define _GNU_SOURCE to get access to the prototype of secure_getenv() Cheers, Andreas -- Andreas Schneider GPG-ID: CC014E3D Samba Team asn(a)samba.org www.samba.org

2 1

[PATCH] examples: convert nettle-benchmark to use openssl EVP APIs
by Daniel P. Berrange 29 Aug '17

29 Aug '17

The nettle-benchmark program currently uses the openssl low level cipher APIs for benchmarking. This means it always runs the generic software implementation, never able to take advantage of impls optimized for new hardware (eg AES-NI). Rewriting it to use the higher EVP APIs means we can use the same code for all ciphers, and automatically trigger hardware optimized versions, giving a fairer comparison against openssl as commonly used in applications. Use of the generic openssl impl can still be forced by setting an env variable OPENSSL_ia32cap="~0x200000200000000" Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- examples/nettle-benchmark.c | 4 + examples/nettle-openssl.c | 247 ++++++++++++++++---------------------------- nettle-internal.h | 1 + 3 files changed, 92 insertions(+), 160 deletions(-) diff --git a/examples/nettle-benchmark.c b/examples/nettle-benchmark.c index c00486cc..11f62709 100644 --- a/examples/nettle-benchmark.c +++ b/examples/nettle-benchmark.c @@ -723,6 +723,10 @@ main(int argc, char **argv) int c; const char *alg; +#if WITH_OPENSSL + nettle_openssl_init(); +#endif + const struct nettle_hash *hashes[] = { &nettle_md2, &nettle_md4, &nettle_md5, diff --git a/examples/nettle-openssl.c b/examples/nettle-openssl.c index 86c5321c..3d7d4fa3 100644 --- a/examples/nettle-openssl.c +++ b/examples/nettle-openssl.c @@ -45,11 +45,9 @@ #include <assert.h> -#include <openssl/aes.h> -#include <openssl/blowfish.h> -#include <openssl/des.h> -#include <openssl/cast.h> -#include <openssl/rc4.h> +#include <openssl/conf.h> +#include <openssl/evp.h> +#include <openssl/err.h> #include <openssl/md5.h> #include <openssl/sha.h> @@ -64,273 +62,202 @@ static nettle_set_key_func openssl_aes192_set_encrypt_key; static nettle_set_key_func openssl_aes192_set_decrypt_key; static nettle_set_key_func openssl_aes256_set_encrypt_key; static nettle_set_key_func openssl_aes256_set_decrypt_key; + +struct AESCipher { + EVP_CIPHER_CTX *ctx; +}; + +void +nettle_openssl_init(void) +{ + ERR_load_crypto_strings(); + OpenSSL_add_all_algorithms(); +#if OPENSSL_VERSION_NUMBER >= 0x1010000 + CONF_modules_load_file(NULL, NULL, 0); +#else + OPENSSL_config(NULL); +#endif +} + +static void +openssl_evp_set_encrypt_key(void *ctx, const uint8_t *key, const EVP_CIPHER *cipher) +{ + EVP_CIPHER_CTX **ctxptr = ctx; + *ctxptr = EVP_CIPHER_CTX_new(); + assert(EVP_EncryptInit_ex(*ctxptr, cipher, NULL, key, NULL) == 1); + EVP_CIPHER_CTX_set_padding(*ctxptr, 0); +} +static void +openssl_evp_set_decrypt_key(void *ctx, const uint8_t *key, const EVP_CIPHER *cipher) +{ + EVP_CIPHER_CTX **ctxptr = ctx; + *ctxptr = EVP_CIPHER_CTX_new(); + assert(EVP_DecryptInit_ex(*ctxptr, cipher, NULL, key, NULL) == 1); + EVP_CIPHER_CTX_set_padding(*ctxptr, 0); +} static void openssl_aes128_set_encrypt_key(void *ctx, const uint8_t *key) { - AES_set_encrypt_key(key, 128, ctx); + openssl_evp_set_encrypt_key(ctx, key, EVP_aes_128_ecb()); } static void openssl_aes128_set_decrypt_key(void *ctx, const uint8_t *key) { - AES_set_decrypt_key(key, 128, ctx); + openssl_evp_set_decrypt_key(ctx, key, EVP_aes_128_ecb()); } static void openssl_aes192_set_encrypt_key(void *ctx, const uint8_t *key) { - AES_set_encrypt_key(key, 192, ctx); + openssl_evp_set_encrypt_key(ctx, key, EVP_aes_192_ecb()); } static void openssl_aes192_set_decrypt_key(void *ctx, const uint8_t *key) { - AES_set_decrypt_key(key, 192, ctx); + openssl_evp_set_decrypt_key(ctx, key, EVP_aes_192_ecb()); } static void openssl_aes256_set_encrypt_key(void *ctx, const uint8_t *key) { - AES_set_encrypt_key(key, 256, ctx); + openssl_evp_set_encrypt_key(ctx, key, EVP_aes_256_ecb()); } static void openssl_aes256_set_decrypt_key(void *ctx, const uint8_t *key) { - AES_set_decrypt_key(key, 256, ctx); + openssl_evp_set_decrypt_key(ctx, key, EVP_aes_256_ecb()); } -static nettle_cipher_func openssl_aes_encrypt; static void -openssl_aes_encrypt(const void *ctx, size_t length, +openssl_evp_encrypt(const void *ctx, size_t length, uint8_t *dst, const uint8_t *src) { - assert (!(length % AES_BLOCK_SIZE)); - while (length) - { - AES_ecb_encrypt(src, dst, ctx, AES_ENCRYPT); - length -= AES_BLOCK_SIZE; - dst += AES_BLOCK_SIZE; - src += AES_BLOCK_SIZE; - } + EVP_CIPHER_CTX * const*ctxptr = ctx; + int len; + assert(EVP_EncryptUpdate(*ctxptr, dst, &len, src, length) == 1); } -static nettle_cipher_func openssl_aes_decrypt; static void -openssl_aes_decrypt(const void *ctx, size_t length, +openssl_evp_decrypt(const void *ctx, size_t length, uint8_t *dst, const uint8_t *src) { - assert (!(length % AES_BLOCK_SIZE)); - while (length) - { - AES_ecb_encrypt(src, dst, ctx, AES_DECRYPT); - length -= AES_BLOCK_SIZE; - dst += AES_BLOCK_SIZE; - src += AES_BLOCK_SIZE; - } + EVP_CIPHER_CTX * const*ctxptr = ctx; + int len; + assert(EVP_DecryptUpdate(*ctxptr, dst, &len, src, length) == 1); } const struct nettle_cipher nettle_openssl_aes128 = { - "openssl aes128", sizeof(AES_KEY), + "openssl aes128", sizeof(EVP_CIPHER_CTX **), 16, 16, openssl_aes128_set_encrypt_key, openssl_aes128_set_decrypt_key, - openssl_aes_encrypt, openssl_aes_decrypt + openssl_evp_encrypt, openssl_evp_decrypt }; const struct nettle_cipher nettle_openssl_aes192 = { - "openssl aes192", sizeof(AES_KEY), - /* Claim no block size, so that the benchmark doesn't try CBC mode - * (as openssl cipher + nettle cbc is somewhat pointless to - * benchmark). */ + "openssl aes192", sizeof(EVP_CIPHER_CTX **), 16, 24, openssl_aes192_set_encrypt_key, openssl_aes192_set_decrypt_key, - openssl_aes_encrypt, openssl_aes_decrypt + openssl_evp_encrypt, openssl_evp_decrypt }; const struct nettle_cipher nettle_openssl_aes256 = { - "openssl aes256", sizeof(AES_KEY), - /* Claim no block size, so that the benchmark doesn't try CBC mode - * (as openssl cipher + nettle cbc is somewhat pointless to - * benchmark). */ + "openssl aes256", sizeof(EVP_CIPHER_CTX **), 16, 32, openssl_aes256_set_encrypt_key, openssl_aes256_set_decrypt_key, - openssl_aes_encrypt, openssl_aes_decrypt + openssl_evp_encrypt, openssl_evp_decrypt }; /* Arcfour */ -static nettle_set_key_func openssl_arcfour128_set_key; static void -openssl_arcfour128_set_key(void *ctx, const uint8_t *key) +openssl_arcfour128_set_encrypt_key(void *ctx, const uint8_t *key) { - RC4_set_key(ctx, 16, key); + openssl_evp_set_encrypt_key(ctx, key, EVP_rc4()); } -static nettle_crypt_func openssl_arcfour_crypt; static void -openssl_arcfour_crypt(void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) +openssl_arcfour128_set_decrypt_key(void *ctx, const uint8_t *key) { - RC4(ctx, length, src, dst); + openssl_evp_set_decrypt_key(ctx, key, EVP_rc4()); } const struct nettle_aead nettle_openssl_arcfour128 = { - "openssl arcfour128", sizeof(RC4_KEY), + "openssl arcfour128", sizeof(EVP_CIPHER_CTX **), 1, 16, 0, 0, - openssl_arcfour128_set_key, - openssl_arcfour128_set_key, + openssl_arcfour128_set_encrypt_key, + openssl_arcfour128_set_decrypt_key, NULL, NULL, - openssl_arcfour_crypt, - openssl_arcfour_crypt, + (nettle_crypt_func *)openssl_evp_encrypt, + (nettle_crypt_func *)openssl_evp_decrypt, NULL, }; /* Blowfish */ -static nettle_set_key_func openssl_bf128_set_key; static void -openssl_bf128_set_key(void *ctx, const uint8_t *key) +openssl_bf128_set_encrypt_key(void *ctx, const uint8_t *key) { - BF_set_key(ctx, 16, key); + openssl_evp_set_encrypt_key(ctx, key, EVP_bf_ecb()); } -static nettle_cipher_func openssl_bf_encrypt; static void -openssl_bf_encrypt(const void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) +openssl_bf128_set_decrypt_key(void *ctx, const uint8_t *key) { - assert (!(length % BF_BLOCK)); - while (length) - { - BF_ecb_encrypt(src, dst, ctx, BF_ENCRYPT); - length -= BF_BLOCK; - dst += BF_BLOCK; - src += BF_BLOCK; - } -} - -static nettle_cipher_func openssl_bf_decrypt; -static void -openssl_bf_decrypt(const void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) -{ - assert (!(length % BF_BLOCK)); - while (length) - { - BF_ecb_encrypt(src, dst, ctx, BF_DECRYPT); - length -= BF_BLOCK; - dst += BF_BLOCK; - src += BF_BLOCK; - } + openssl_evp_set_decrypt_key(ctx, key, EVP_bf_ecb()); } const struct nettle_cipher nettle_openssl_blowfish128 = { - "openssl bf128", sizeof(BF_KEY), + "openssl bf128", sizeof(EVP_CIPHER_CTX **), 8, 16, - openssl_bf128_set_key, openssl_bf128_set_key, - openssl_bf_encrypt, openssl_bf_decrypt + openssl_bf128_set_encrypt_key, openssl_bf128_set_decrypt_key, + openssl_evp_encrypt, openssl_evp_decrypt }; /* DES */ -static nettle_set_key_func openssl_des_set_key; -static void -openssl_des_set_key(void *ctx, const uint8_t *key) -{ - /* Not sure what "unchecked" means. We want to ignore parity bits, - but it would still make sense to check for weak keys. */ - /* Explicit cast used as I don't want to care about openssl's broken - array typedefs DES_cblock and const_DES_cblock. */ - DES_set_key_unchecked( (void *) key, ctx); -} - -#define DES_BLOCK_SIZE 8 - -static nettle_cipher_func openssl_des_encrypt; static void -openssl_des_encrypt(const void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) +openssl_des_set_encrypt_key(void *ctx, const uint8_t *key) { - assert (!(length % DES_BLOCK_SIZE)); - while (length) - { - DES_ecb_encrypt((void *) src, (void *) dst, - (void *) ctx, DES_ENCRYPT); - length -= DES_BLOCK_SIZE; - dst += DES_BLOCK_SIZE; - src += DES_BLOCK_SIZE; - } + openssl_evp_set_encrypt_key(ctx, key, EVP_des_ecb()); } -static nettle_cipher_func openssl_des_decrypt; static void -openssl_des_decrypt(const void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) +openssl_des_set_decrypt_key(void *ctx, const uint8_t *key) { - assert (!(length % DES_BLOCK_SIZE)); - while (length) - { - DES_ecb_encrypt((void *) src, (void *) dst, - (void *) ctx, DES_DECRYPT); - length -= DES_BLOCK_SIZE; - dst += DES_BLOCK_SIZE; - src += DES_BLOCK_SIZE; - } + openssl_evp_set_decrypt_key(ctx, key, EVP_des_ecb()); } const struct nettle_cipher nettle_openssl_des = { - "openssl des", sizeof(DES_key_schedule), + "openssl des", sizeof(EVP_CIPHER_CTX **), 8, 8, - openssl_des_set_key, openssl_des_set_key, - openssl_des_encrypt, openssl_des_decrypt + openssl_des_set_encrypt_key, openssl_des_set_decrypt_key, + openssl_evp_encrypt, openssl_evp_decrypt }; /* Cast128 */ -static nettle_set_key_func openssl_cast128_set_key; static void -openssl_cast128_set_key(void *ctx, const uint8_t *key) +openssl_cast128_set_encrypt_key(void *ctx, const uint8_t *key) { - CAST_set_key(ctx, 16, key); + openssl_evp_set_encrypt_key(ctx, key, EVP_cast5_ecb()); } -static nettle_cipher_func openssl_cast_encrypt; static void -openssl_cast_encrypt(const void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) +openssl_cast128_set_decrypt_key(void *ctx, const uint8_t *key) { - assert (!(length % CAST_BLOCK)); - while (length) - { - CAST_ecb_encrypt(src, dst, ctx, CAST_ENCRYPT); - length -= CAST_BLOCK; - dst += CAST_BLOCK; - src += CAST_BLOCK; - } -} - -static nettle_cipher_func openssl_cast_decrypt; -static void -openssl_cast_decrypt(const void *ctx, size_t length, - uint8_t *dst, const uint8_t *src) -{ - assert (!(length % CAST_BLOCK)); - while (length) - { - CAST_ecb_encrypt(src, dst, ctx, CAST_DECRYPT); - length -= CAST_BLOCK; - dst += CAST_BLOCK; - src += CAST_BLOCK; - } + openssl_evp_set_decrypt_key(ctx, key, EVP_cast5_ecb()); } const struct nettle_cipher nettle_openssl_cast128 = { - "openssl cast128", sizeof(CAST_KEY), - 8, CAST_KEY_LENGTH, - openssl_cast128_set_key, openssl_cast128_set_key, - openssl_cast_encrypt, openssl_cast_decrypt + "openssl cast128", sizeof(EVP_CIPHER_CTX **), + 8, 16, + openssl_cast128_set_encrypt_key, openssl_cast128_set_decrypt_key, + openssl_evp_encrypt, openssl_evp_decrypt }; /* Hash functions */ diff --git a/nettle-internal.h b/nettle-internal.h index 9c4c699d..0b0d25c9 100644 --- a/nettle-internal.h +++ b/nettle-internal.h @@ -79,6 +79,7 @@ extern const struct nettle_aead nettle_salsa20r12; /* Glue to openssl, for comparative benchmarking. Code in * examples/nettle-openssl.c. */ +extern void nettle_openssl_init(void); extern const struct nettle_cipher nettle_openssl_aes128; extern const struct nettle_cipher nettle_openssl_aes192; extern const struct nettle_cipher nettle_openssl_aes256; -- 2.13.3

2 3

[PATCH v2] Add support for reading/writing integers in Little Endian format
by Dmitry Eremin-Solenikov 29 Aug '17

29 Aug '17

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> --- bignum.c | 35 +++++++++++++++++++++++++++++++++++ bignum.h | 17 +++++++++++++++++ testsuite/bignum-test.c | 29 +++++++++++++++++++++++++++++ 3 files changed, 81 insertions(+) diff --git a/bignum.c b/bignum.c index 335252876544..413a630cb3aa 100644 --- a/bignum.c +++ b/bignum.c @@ -133,12 +133,32 @@ nettle_mpz_get_str_256(size_t length, uint8_t *s, const mpz_t x) } } +void +nettle_mpz_get_str_256_u_le(size_t length, uint8_t *s, const mpz_t x) +{ + if (!length) + { + /* x must be zero */ + assert(!mpz_sgn(x)); + return; + } + + size_t count; + + assert(nettle_mpz_sizeinbase_256_u(x) <= length); + mpz_export(s, &count, -1, 1, 0, 0, x); + memset(s + count, 0, length - count); +} + /* Converting from strings */ /* mpz_import was introduced in GMP-4.1 */ #define nettle_mpz_from_octets(x, length, s) \ mpz_import((x), (length), 1, 1, 0, 0, (s)) +#define nettle_mpz_from_octets_le(x, length, s) \ + mpz_import((x), (length), -1, 1, 0, 0, (s)) + void nettle_mpz_set_str_256_u(mpz_t x, size_t length, const uint8_t *s) @@ -154,6 +174,21 @@ nettle_mpz_init_set_str_256_u(mpz_t x, nettle_mpz_from_octets(x, length, s); } +void +nettle_mpz_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s) +{ + nettle_mpz_from_octets_le(x, length, s); +} + +void +nettle_mpz_init_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s) +{ + mpz_init(x); + nettle_mpz_from_octets_le(x, length, s); +} + void nettle_mpz_set_str_256_s(mpz_t x, size_t length, const uint8_t *s) diff --git a/bignum.h b/bignum.h index 9afcd299f8ed..87dd2d12dc3f 100644 --- a/bignum.h +++ b/bignum.h @@ -67,11 +67,19 @@ nettle_mpz_sizeinbase_256_s(const mpz_t x); size_t nettle_mpz_sizeinbase_256_u(const mpz_t x); +#define nettle_mpz_sizeinbase_256_u_le nettle_mpz_sizeinbase_256_u + /* Writes an integer as length octets, using big endian byte order, * and two's complement for negative numbers. */ void nettle_mpz_get_str_256(size_t length, uint8_t *s, const mpz_t x); +/* Writes an integer as length octets, using big endian byte order, + * and unsigned number format. */ +void +nettle_mpz_get_str_256_u_le(size_t length, uint8_t *s, const mpz_t x); + + /* Reads a big endian, two's complement, integer. */ void nettle_mpz_set_str_256_s(mpz_t x, @@ -91,6 +99,15 @@ void nettle_mpz_init_set_str_256_u(mpz_t x, size_t length, const uint8_t *s); +/* Similar, but for little endian byte order. */ +void +nettle_mpz_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s); + +void +nettle_mpz_init_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s); + /* Returns a uniformly distributed random number 0 <= x < 2^n */ void nettle_mpz_random_size(mpz_t x, diff --git a/testsuite/bignum-test.c b/testsuite/bignum-test.c index 602554b53941..79fd92e2d37d 100644 --- a/testsuite/bignum-test.c +++ b/testsuite/bignum-test.c @@ -34,6 +34,30 @@ test_bignum(const char *hex, const struct tstring *base256) free(buf); } +static void +test_bignum_le(const char *hex, const struct tstring *base256) +{ + mpz_t a; + mpz_t b; + uint8_t *buf; + + mpz_init_set_str(a, hex, 16); + nettle_mpz_init_set_str_256_u_le(b, base256->length, base256->data); + + ASSERT(mpz_cmp(a, b) == 0); + + buf = xalloc(base256->length + 1); + memset(buf, 17, base256->length + 1); + + nettle_mpz_get_str_256_u_le(base256->length, buf, a); + ASSERT(MEMEQ(base256->length, buf, base256->data)); + + ASSERT(buf[base256->length] == 17); + + mpz_clear(a); mpz_clear(b); + free(buf); +} + static void test_size(long x, unsigned size) { @@ -86,6 +110,11 @@ test_main(void) test_bignum("-7fff", SHEX( "8001")); test_bignum("-8000", SHEX( "8000")); test_bignum("-8001", SHEX("ff7fff")); + + test_bignum_le("0", SHEX("00")); + test_bignum_le("010203040506", SHEX("060504030201")); + test_bignum_le("80010203040506", SHEX("06050403020180")); + test_bignum_le("01020304050680", SHEX("80060504030201")); #else /* !WITH_HOGWEED */ SKIP(); -- 2.14.1

1 0

[PATCH] Add support for reading/writing integers in Little Endian format
by Dmitry Eremin-Solenikov 28 Aug '17

28 Aug '17

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> --- bignum.c | 35 +++++++++++++++++++++++++++++++++++ bignum.h | 15 +++++++++++++++ testsuite/bignum-test.c | 29 +++++++++++++++++++++++++++++ 3 files changed, 79 insertions(+) diff --git a/bignum.c b/bignum.c index 335252876544..413a630cb3aa 100644 --- a/bignum.c +++ b/bignum.c @@ -133,12 +133,32 @@ nettle_mpz_get_str_256(size_t length, uint8_t *s, const mpz_t x) } } +void +nettle_mpz_get_str_256_u_le(size_t length, uint8_t *s, const mpz_t x) +{ + if (!length) + { + /* x must be zero */ + assert(!mpz_sgn(x)); + return; + } + + size_t count; + + assert(nettle_mpz_sizeinbase_256_u(x) <= length); + mpz_export(s, &count, -1, 1, 0, 0, x); + memset(s + count, 0, length - count); +} + /* Converting from strings */ /* mpz_import was introduced in GMP-4.1 */ #define nettle_mpz_from_octets(x, length, s) \ mpz_import((x), (length), 1, 1, 0, 0, (s)) +#define nettle_mpz_from_octets_le(x, length, s) \ + mpz_import((x), (length), -1, 1, 0, 0, (s)) + void nettle_mpz_set_str_256_u(mpz_t x, size_t length, const uint8_t *s) @@ -154,6 +174,21 @@ nettle_mpz_init_set_str_256_u(mpz_t x, nettle_mpz_from_octets(x, length, s); } +void +nettle_mpz_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s) +{ + nettle_mpz_from_octets_le(x, length, s); +} + +void +nettle_mpz_init_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s) +{ + mpz_init(x); + nettle_mpz_from_octets_le(x, length, s); +} + void nettle_mpz_set_str_256_s(mpz_t x, size_t length, const uint8_t *s) diff --git a/bignum.h b/bignum.h index 9afcd299f8ed..afea1887e73c 100644 --- a/bignum.h +++ b/bignum.h @@ -72,6 +72,12 @@ nettle_mpz_sizeinbase_256_u(const mpz_t x); void nettle_mpz_get_str_256(size_t length, uint8_t *s, const mpz_t x); +/* Writes an integer as length octets, using big endian byte order, + * and unsigned number format. */ +void +nettle_mpz_get_str_256_u_le(size_t length, uint8_t *s, const mpz_t x); + + /* Reads a big endian, two's complement, integer. */ void nettle_mpz_set_str_256_s(mpz_t x, @@ -91,6 +97,15 @@ void nettle_mpz_init_set_str_256_u(mpz_t x, size_t length, const uint8_t *s); +/* Similar, but for little endian byte order. */ +void +nettle_mpz_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s); + +void +nettle_mpz_init_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s); + /* Returns a uniformly distributed random number 0 <= x < 2^n */ void nettle_mpz_random_size(mpz_t x, diff --git a/testsuite/bignum-test.c b/testsuite/bignum-test.c index 602554b53941..79fd92e2d37d 100644 --- a/testsuite/bignum-test.c +++ b/testsuite/bignum-test.c @@ -34,6 +34,30 @@ test_bignum(const char *hex, const struct tstring *base256) free(buf); } +static void +test_bignum_le(const char *hex, const struct tstring *base256) +{ + mpz_t a; + mpz_t b; + uint8_t *buf; + + mpz_init_set_str(a, hex, 16); + nettle_mpz_init_set_str_256_u_le(b, base256->length, base256->data); + + ASSERT(mpz_cmp(a, b) == 0); + + buf = xalloc(base256->length + 1); + memset(buf, 17, base256->length + 1); + + nettle_mpz_get_str_256_u_le(base256->length, buf, a); + ASSERT(MEMEQ(base256->length, buf, base256->data)); + + ASSERT(buf[base256->length] == 17); + + mpz_clear(a); mpz_clear(b); + free(buf); +} + static void test_size(long x, unsigned size) { @@ -86,6 +110,11 @@ test_main(void) test_bignum("-7fff", SHEX( "8001")); test_bignum("-8000", SHEX( "8000")); test_bignum("-8001", SHEX("ff7fff")); + + test_bignum_le("0", SHEX("00")); + test_bignum_le("010203040506", SHEX("060504030201")); + test_bignum_le("80010203040506", SHEX("06050403020180")); + test_bignum_le("01020304050680", SHEX("80060504030201")); #else /* !WITH_HOGWEED */ SKIP(); -- 2.14.1

1 0

[PATCH] ecc-mod-arith.c: expose mpn_mul_n invariant violation
by Sergei Trofimovich 23 Jul '17

23 Jul '17

GMP's mpn_mul_n must never take overlapping source and destination buffers as the implementation makes a few passes over source while updating destination at each pass: ``` https://gmplib.org/manual/Low_002dlevel-Functions.html#Low_002dlevel-Functi… Function: void mpn_mul_n (mp_limb_t *rp, const mp_limb_t *s1p, const mp_limb_t *s2p, mp_size_t n) Multiply {s1p, n} and {s2p, n}, and write the 2*n-limb result to rp. The destination has to have space for 2*n limbs, even if the product’s most significant limb is zero. No overlap is permitted between the destination and either source. ``` Violation of this invariant make nettle to compute curve25519 incorrectly at least on sparc and hppa architectures, see https://bugs.gentoo.org/613418 for some details. The overlap happens in `ecc-add-eh.c` where layout of local GMP variables on scratch space is the following: ``` |x1|y1|z1|........|B| |x3|y3|z3|... ``` x1/x3, y1/y3, z1/z3 pairs share the same memory region. Overlap happens at a call of ``` ecc_modp_mul (ecc, y3, B, z1); ``` which is basically ``` mpn_mul_n (y3, B, z1, m->size), ``` Note how y3 overwrites z1. This is scary type of aliasing. The bug manifested in testsuite failure in nettle and gnutls. I've trailed the bug down to faulty function by adding printf() and comparing exact output of scratch space on x86 versus sparc. `mpn_mul_n` on the same source numbers produces different results. This change does not fix the underlying overlap but exposes the problem on all architectures and crashes the testsuitewith asset(). Reported-by: Matt Turner Bug: https://bugs.gentoo.org/613418 Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- ecc-mod-arith.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/ecc-mod-arith.c b/ecc-mod-arith.c index f2e47f67..735b1238 100644 --- a/ecc-mod-arith.c +++ b/ecc-mod-arith.c @@ -109,11 +109,23 @@ ecc_mod_submul_1 (const struct ecc_modulo *m, mp_limb_t *rp, assert (hi == 0); } +static int no_overlap(const mp_limb_t * a, size_t la, + const mp_limb_t * b, size_t lb) +{ + if (a < b) + return (size_t)(b - a) >= la; + /* a >= b */ + return (size_t)(a - b) >= lb; +} + /* NOTE: mul and sqr needs 2*m->size limbs at rp */ void ecc_mod_mul (const struct ecc_modulo *m, mp_limb_t *rp, const mp_limb_t *ap, const mp_limb_t *bp) { + /* NOTE: mpn_mul_n does not work correctly when source and destination overlap */ + assert (no_overlap (rp, 2 * m->size, ap, m->size)); + assert (no_overlap (rp, 2 * m->size, bp, m->size)); mpn_mul_n (rp, ap, bp, m->size); m->reduce (m, rp); } -- 2.13.3

3 6

[PATCH] Avoid assertion failure in pss_verify_mgf1
by Daiki Ueno 10 Jun '17

10 Jun '17

Hello, Nikos told me that there is a case where RSA-PSS signature verification leads to an assertion failure: bignum.c:120: nettle_mpz_get_str_256: Assertion `nettle_mpz_sizeinbase_256_u(x) <= length' failed. I thought it wouldn't be possible because 'x' is already rounded by the RSA modulus and 'length' is bound to the modulus. However, actually 'length' is calculated as ((modBits - 1) + 7) / 8, i.e. one bit less than the original modulus. Thus, it would be possible that the octet length of 'x' exceeds 'length'. I am attaching a patch for this. Regards, -- Daiki Ueno

3 6

[PATCH 00/13] GOST cipher/MAC/hash algorithms support
by Dmitry Eremin-Solenikov 07 Jun '17

07 Jun '17

This is the first round of patches expanding GOST algorithms support in Nettle cryptographic library. They are implemented according to published RFCs and GOST standards and serve the base of GOST ciphersuites implementation for GnuTLS. Dmitry Eremin-Solenikov (13): Add GOST R 34.11 to nettle_hashes Add HMAC functions for GOSTHASH94 Start separating GOST 28147-89 from GOST R 34.11-94 Add support for GOSTHASH94CP: GOST R 34.11-94 hash with CryptoPro S-box Implement PBKDF2 shortcut function for GOSTHASH94CP Add the rest of sboxes for GOST 28147 Add GOST 28147-89 ECB encryption and decryption support Add CFB block mode support Add CFB mode support for GOST 28147-89 Add special CNT mode for GOST 28147-89 cipher Add GOST 28147-89 IMIT support Implement GOST R 34.11-2012 (Streebog) hash function Implement PBKDF2 shortcut function for Streebog256/512 Makefile.in | 15 +- cfb.c | 176 +++ cfb.h | 87 ++ examples/nettle-benchmark.c | 2 + gost28147-meta.c | 49 + gost28147.c | 2546 ++++++++++++++++++++++++++++++++++++++++++ gost28147.h | 183 +++ gosthash94-meta.c | 3 + gosthash94.c | 321 ++---- gosthash94.h | 13 + hmac-gosthash94.c | 79 ++ hmac-streebog.c | 73 ++ hmac.h | 70 ++ nettle-meta-ciphers.c | 1 + nettle-meta-hashes.c | 4 + nettle-meta.h | 5 + nettle.texinfo | 257 ++++- pbkdf2-hmac-gosthash94.c | 54 + pbkdf2-hmac-streebog.c | 67 ++ pbkdf2.h | 21 + streebog-meta.c | 44 + streebog.c | 1332 ++++++++++++++++++++++ streebog.h | 99 ++ testsuite/.gitignore | 3 + testsuite/.test-rules.make | 9 + testsuite/Makefile.in | 4 +- testsuite/cfb-test.c | 287 +++++ testsuite/gost28147-test.c | 505 +++++++++ testsuite/gosthash94-test.c | 12 + testsuite/hmac-test.c | 31 + testsuite/meta-cipher-test.c | 1 + testsuite/meta-hash-test.c | 4 + testsuite/pbkdf2-test.c | 61 +- testsuite/streebog-test.c | 40 + testsuite/testutils.c | 179 +++ testsuite/testutils.h | 7 + 36 files changed, 6372 insertions(+), 272 deletions(-) create mode 100644 cfb.c create mode 100644 cfb.h create mode 100644 gost28147-meta.c create mode 100644 gost28147.c create mode 100644 gost28147.h create mode 100644 hmac-gosthash94.c create mode 100644 hmac-streebog.c create mode 100644 pbkdf2-hmac-gosthash94.c create mode 100644 pbkdf2-hmac-streebog.c create mode 100644 streebog-meta.c create mode 100644 streebog.c create mode 100644 streebog.h create mode 100644 testsuite/cfb-test.c create mode 100644 testsuite/gost28147-test.c create mode 100644 testsuite/streebog-test.c -- 2.11.0

2 16

RSA OAEP Support
by Aapo Talvensaari 29 May '17

29 May '17

Some 8 years ago this was added to rsa.h: /* These functions uses the v1.5 padding. What should the v2 (OAEP) > * functions be called? *//* RSA encryption, using PKCS#1 */ Has there been any work since then to support OAEP? Regards Aapo

2 1

[PATCH] Add support for reading/writing integers in Little Endian format
by Dmitry Eremin-Solenikov 24 May '17

24 May '17

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> --- bignum.c | 35 +++++++++++++++++++++++++++++++++++ bignum.h | 15 +++++++++++++++ testsuite/bignum-test.c | 29 +++++++++++++++++++++++++++++ 3 files changed, 79 insertions(+) diff --git a/bignum.c b/bignum.c index 33525287..413a630c 100644 --- a/bignum.c +++ b/bignum.c @@ -133,12 +133,32 @@ nettle_mpz_get_str_256(size_t length, uint8_t *s, const mpz_t x) } } +void +nettle_mpz_get_str_256_u_le(size_t length, uint8_t *s, const mpz_t x) +{ + if (!length) + { + /* x must be zero */ + assert(!mpz_sgn(x)); + return; + } + + size_t count; + + assert(nettle_mpz_sizeinbase_256_u(x) <= length); + mpz_export(s, &count, -1, 1, 0, 0, x); + memset(s + count, 0, length - count); +} + /* Converting from strings */ /* mpz_import was introduced in GMP-4.1 */ #define nettle_mpz_from_octets(x, length, s) \ mpz_import((x), (length), 1, 1, 0, 0, (s)) +#define nettle_mpz_from_octets_le(x, length, s) \ + mpz_import((x), (length), -1, 1, 0, 0, (s)) + void nettle_mpz_set_str_256_u(mpz_t x, size_t length, const uint8_t *s) @@ -155,6 +175,21 @@ nettle_mpz_init_set_str_256_u(mpz_t x, } void +nettle_mpz_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s) +{ + nettle_mpz_from_octets_le(x, length, s); +} + +void +nettle_mpz_init_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s) +{ + mpz_init(x); + nettle_mpz_from_octets_le(x, length, s); +} + +void nettle_mpz_set_str_256_s(mpz_t x, size_t length, const uint8_t *s) { diff --git a/bignum.h b/bignum.h index 9afcd299..afea1887 100644 --- a/bignum.h +++ b/bignum.h @@ -72,6 +72,12 @@ nettle_mpz_sizeinbase_256_u(const mpz_t x); void nettle_mpz_get_str_256(size_t length, uint8_t *s, const mpz_t x); +/* Writes an integer as length octets, using big endian byte order, + * and unsigned number format. */ +void +nettle_mpz_get_str_256_u_le(size_t length, uint8_t *s, const mpz_t x); + + /* Reads a big endian, two's complement, integer. */ void nettle_mpz_set_str_256_s(mpz_t x, @@ -91,6 +97,15 @@ void nettle_mpz_init_set_str_256_u(mpz_t x, size_t length, const uint8_t *s); +/* Similar, but for little endian byte order. */ +void +nettle_mpz_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s); + +void +nettle_mpz_init_set_str_256_u_le(mpz_t x, + size_t length, const uint8_t *s); + /* Returns a uniformly distributed random number 0 <= x < 2^n */ void nettle_mpz_random_size(mpz_t x, diff --git a/testsuite/bignum-test.c b/testsuite/bignum-test.c index 602554b5..79fd92e2 100644 --- a/testsuite/bignum-test.c +++ b/testsuite/bignum-test.c @@ -35,6 +35,30 @@ test_bignum(const char *hex, const struct tstring *base256) } static void +test_bignum_le(const char *hex, const struct tstring *base256) +{ + mpz_t a; + mpz_t b; + uint8_t *buf; + + mpz_init_set_str(a, hex, 16); + nettle_mpz_init_set_str_256_u_le(b, base256->length, base256->data); + + ASSERT(mpz_cmp(a, b) == 0); + + buf = xalloc(base256->length + 1); + memset(buf, 17, base256->length + 1); + + nettle_mpz_get_str_256_u_le(base256->length, buf, a); + ASSERT(MEMEQ(base256->length, buf, base256->data)); + + ASSERT(buf[base256->length] == 17); + + mpz_clear(a); mpz_clear(b); + free(buf); +} + +static void test_size(long x, unsigned size) { mpz_t t; @@ -86,6 +110,11 @@ test_main(void) test_bignum("-7fff", SHEX( "8001")); test_bignum("-8000", SHEX( "8000")); test_bignum("-8001", SHEX("ff7fff")); + + test_bignum_le("0", SHEX("00")); + test_bignum_le("010203040506", SHEX("060504030201")); + test_bignum_le("80010203040506", SHEX("06050403020180")); + test_bignum_le("01020304050680", SHEX("80060504030201")); #else /* !WITH_HOGWEED */ SKIP(); -- 2.11.0

1 0

Request to support more KDFs
by Gabriel Ivașcu 18 May '17

18 May '17

Dear Nettle developers, I see Nettle currently supports only some variations of PBKDF2 so I was wondering whether there could be added support for more KDFs [0]. In my particular case it would be nice to have support for HKDF [1]. HKDF is not complicated and I'm sure most of us can work with their own implementation (like I did in my projects), but I believe it will be more beneficial for users to have it properly implemented in Nettle. Same goes for the other KDFs. [0] https://en.wikipedia.org/wiki/Category:Key_derivation_functions [1] https://tools.ietf.org/html/rfc5869 Thanks, Gabriel

2 1

Please use https in mail footer
by Tim Rühsen 17 May '17

17 May '17

Could you (the admin) change the footer to use https instead of http, please ? With Best Regards, Tim

1 0

static analyzer run + few fixes
by Nikos Mavrogiannopoulos 16 May '17

16 May '17

Hi Niels, The attached patches add a static analyzer run in the nettle CI and fix few minor issues found with it. There two issues I didn't fix because I am not sure whether it is a logical error or an initialization of the variables in question could solve it. I attach the html output of scan-view. Both involve the ecc_mod() function and the variable 'hi'. regards, Nikos

2 1

Up to 7x faster sha256 for ppc64le: Please review
by Gustavo Serra Scalet 09 Apr '17

09 Apr '17

Hi, I coded a high performance sha256 algorithm for ppc64le: https://git.lysator.liu.se/gut/nettle/commit/a8facb03a69787a93c91b426f32a0b… Tests were performed with different files and comparing it against the original C implementation by using the Ubuntu's 16.10 libnettle.so.6 by using the following code: https://gist.github.com/gut/9622d4535a9e3f9ea3b0ded2762d4b28 The results I got by using an ubuntu-16.10 iso as an input (around 700mb): $ time ./sha256-test ~/ubuntu-16.10-server-ppc64el.iso d14bdb413ea6cdc8d9354fcbc37a834b7de0c23f992deb0c6764d0fd5d65408e real 0m14.607s user 0m13.988s sys 0m0.616s $ export LD_LIBRARY_PATH=~/nettle # link with user and not system lib $ time ./sha256-test ~/ubuntu-16.10-server-ppc64el.iso d14bdb413ea6cdc8d9354fcbc37a834b7de0c23f992deb0c6764d0fd5d65408e real 0m2.242s user 0m2.052s sys 0m0.188s I also plan on doing the sha512 if I'm heading to the right direction. Regards, Gustavo Serra Scalet > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos@gmail.com] > Sent: terça-feira, 28 de fevereiro de 2017 06:07 > To: Niels Möller <nisse(a)lysator.liu.se> > Cc: Gustavo Serra Scalet <gustavo.scalet(a)eldorado.org.br>; nettle- > bugs(a)lists.lysator.liu.se > Subject: Re: Is the gitlab being used or not? > > On Tue, Feb 28, 2017 at 7:48 AM, Niels Möller <nisse(a)lysator.liu.se> > wrote: > > Gustavo Serra Scalet <gustavo.scalet(a)eldorado.org.br> writes: > > > >> I noticed there is no merging/update activities on the gitlab > website: > >> https://git.lysator.liu.se/nettle/nettle/merge_requests?scope=all&sta > >> te=all > >> > >> I wonder if it's used. > > > > It's used mainly for the plain git hosting. I rarely use the more > > advance features, and almost never access the web interface. > > Would it be possible to disable then the merge request option in the > gitlab interface? There are already 5 patches there. > > Most likely you need to go to -> Edit project and disable the issue > tracker and the merge commits for everyone (at least that's the process > in the new gitlab). > > >> The reason for asking is that I'm willing to integrate a > >> ppc64le-specific implementation using SIMD registers for the SHA-2 > >> algorithm so I would create an Issue to discuss it and then > >> submitting the code as a Merge Request. But only if that's the way > >> for upstreaming code on nettle. If not, please advise if this list > >> can be used. > > > > Discussion should take place on this list. You can mail patches here, > > or create a merge request on gitlab. But in the latter case, please > > send a note here too, otherwise it might be overlooked. > > I attach a patch to document that process. I use CONTRIBUTION.md show it > shows prominently on the gitlab interfaces. > > regards, > Nikos

2 4

Is the gitlab being used or not?
by Gustavo Serra Scalet 09 Apr '17

09 Apr '17

Hi, I noticed there is no merging/update activities on the gitlab website: https://git.lysator.liu.se/nettle/nettle/merge_requests?scope=all&state=all I wonder if it's used. The reason for asking is that I'm willing to integrate a ppc64le-specific implementation using SIMD registers for the SHA-2 algorithm so I would create an Issue to discuss it and then submitting the code as a Merge Request. But only if that's the way for upstreaming code on nettle. If not, please advise if this list can be used. Sorry for using the "nettle-bugs" mailing list, which is not a discussion mailing list. Cheers, Gustavo Serra Scalet

3 3

[PATCH 0/2] Implement RSA-PSS signature scheme
by Daiki Ueno 14 Mar '17

14 Mar '17

From: Daiki Ueno <dueno(a)redhat.com> Hello, This series of patches implements the RSA-PSS signature scheme, as specified in RFC 3447. To keep the interface minimal but to allow TLS 1.3 implementations on top of this, only SHA256/384/512 variants are provided. The prototypes of the top-level functions are as follows: int rsa_pss_shaXXX_sign_digest_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func *random, size_t salt_length, const uint8_t *salt, const uint8_t *digest, mpz_t s); int rsa_pss_shaXXX_verify_digest(const struct rsa_public_key *key, size_t salt_length, const uint8_t *digest, const mpz_t signature); For MGF, "mask generation function 1" backed by the same hash algorithm is always used, as indicated in [1]. I thought it might make sense to provide more flexible variants, such as rsa_pss_{sign_tr,verify} analogous to rsa_pkcs1_*, but realized that parsing ASN.1 encoded parameters would require extra complexity. Suggestions appreciated. Daiki Ueno (2): Implement PSS encoding functions Add PSS variants for RSA sign/verify functions Makefile.in | 7 +- mgf1-sha256.c | 47 +++++++ mgf1-sha384.c | 47 +++++++ mgf1-sha512.c | 47 +++++++ mgf1.c | 72 +++++++++++ mgf1.h | 70 ++++++++++ nettle-types.h | 3 + nettle.texinfo | 30 +++++ pss-sha256.c | 64 ++++++++++ pss-sha512.c | 90 +++++++++++++ pss.c | 195 ++++++++++++++++++++++++++++ pss.h | 105 +++++++++++++++ rsa-pss-sha256-sign-tr.c | 64 ++++++++++ rsa-pss-sha256-verify.c | 60 +++++++++ rsa-pss-sha512-sign-tr.c | 87 +++++++++++++ rsa-pss-sha512-verify.c | 79 ++++++++++++ rsa-verify.c | 14 ++ rsa.h | 55 ++++++++ testsuite/.test-rules.make | 9 ++ testsuite/Makefile.in | 5 +- testsuite/mgf1-test.c | 23 ++++ testsuite/pss-test.c | 35 +++++ testsuite/rsa-pss-sign-tr-test.c | 268 +++++++++++++++++++++++++++++++++++++++ 23 files changed, 1473 insertions(+), 3 deletions(-) create mode 100644 mgf1-sha256.c create mode 100644 mgf1-sha384.c create mode 100644 mgf1-sha512.c create mode 100644 mgf1.c create mode 100644 mgf1.h create mode 100644 pss-sha256.c create mode 100644 pss-sha512.c create mode 100644 pss.c create mode 100644 pss.h create mode 100644 rsa-pss-sha256-sign-tr.c create mode 100644 rsa-pss-sha256-verify.c create mode 100644 rsa-pss-sha512-sign-tr.c create mode 100644 rsa-pss-sha512-verify.c create mode 100644 testsuite/mgf1-test.c create mode 100644 testsuite/pss-test.c create mode 100644 testsuite/rsa-pss-sign-tr-test.c Footnotes: [1] https://tlswg.github.io/tls13-spec/#signature-algorithms -- 2.9.3

3 5

[PATCH] Make nettle compile with pre-UAL arm assembler.
by Marcus Hoffmann 09 Mar '17

09 Mar '17

See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjagjj… The pre-UAL instruction is also accepted by modern assemblers. Signed-off-by: Marcus Hoffmann <m.hoffmann(a)cartelsol.com> --- arm/ecc-521-modp.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arm/ecc-521-modp.asm b/arm/ecc-521-modp.asm index c311a89..3fba239 100644 --- a/arm/ecc-521-modp.asm +++ b/arm/ecc-521-modp.asm @@ -91,7 +91,7 @@ PROLOGUE(nettle_ecc_521_modp) adcs F0, F0, F3, lsr #9 C Copy low 9 bits to H, then shift right including carry and H, F0, T0 - rrx F0, F0 + mov F0, F0, rrx lsr F0, F0, #8 C Add in F1 = rp[33], with weight 2^1056 = 2^14 adds F0, F0, F1, lsl #14 -- 2.9.3

2 1

Re: How to pass an IV to the AES 256 encryption/decryption
by Gabriel Ivașcu 04 Mar '17

04 Mar '17

On Sat, Mar 4, 2017 at 2:31 PM, Aapo Talvensaari <aapo.talvensaari(a)gmail.com> wrote: > On Sat, Mar 4, 2017 at 12:18 PM, Gabriel Ivașcu <ivascu.gabriel59(a)gmail.com> > wrote: >> >> Hi, >> >> Can I get some instructions on how to use an IV (initialization >> vector) when doing an AES 256 encryption/decryption? >> >> The AES documentation [0] provides no information on how to pass the >> IV to the AES functions, > > > Please check here: > https://github.com/bungle/lua-resty-nettle/blob/master/lib/resty/nettle/aes… > Thanks for your response, Aapo! I learned eventually that you have to explicitly use the CBC mode [0] if you want to pass an IV, since the AES functions [1] use the ECB mode as default. Also, I found this useful example [2] of how use the CBC mode with Twofish, which I adapted to use AES instead. [0] https://www.lysator.liu.se/~nisse/nettle/nettle.html#CBC [1] https://www.lysator.liu.se/~nisse/nettle/nettle.html#AES [2] https://stackoverflow.com/questions/33003118/nettle-twofish-cbc Regards, Gabriel

1 0

How to pass an IV to the AES 256 encryption/decryption
by Gabriel Ivașcu 04 Mar '17

04 Mar '17

Hi, Can I get some instructions on how to use an IV (initialization vector) when doing an AES 256 encryption/decryption? The AES documentation [0] provides no information on how to pass the IV to the AES functions. [0] https://www.lysator.liu.se/~nisse/nettle/nettle.html#AES Thank you, Gabriel

1 0

lock-free random generator
by Nikos Mavrogiannopoulos 28 Feb '17

28 Feb '17

Hi, One of the items that have been on my todo-list after discussing with application writers of multi-threaded applications (mainly servers), is addressing the issue of synchronization for the random generator. Currently gnutls provides a "central" random generator based on yarrow (for keys) and salsa20 (for nonces) primitives, and it is thread safe by utilizing mutexes over it. An application that has more than 100-200 threads is most likely to spend more time in synchronization rather than the random generator itself. A solution to that would be to provide a thread-local random generator which will work lock-free, at the cost of additional memory per-thread -around 600-700 bytes for the current generator-. I have an experimental patch set, implementing this idea at: https://gitlab.com/gnutls/gnutls/merge_requests/259 On the patch above, the additional cost per thread will only be for threads actually utilizing gnutls, and in particular the random generator, as the required memory will be allocated after the first call to gnutls_rnd() by the thread. Are there any objections on such an enhancement to gnutls, or suggestions on how such a lock-free random generator could be improved (in terms of memory utilization for example)? regards, Nikos

2 5

detecting sha1 collisions
by Nikos Mavrogiannopoulos 24 Feb '17

24 Feb '17

Hi, There is a sha1 collision detection library at: https://github.com/cr-marcstevens/sha1collisiondetection Given that algorithms like sha1 are notoriously hard to phase out, does it make sense for nettle to add support for collision detection, in effect giving applications the option to switch to a mode where a known to be insecure hash is enabled, but with such collision detection mitigations in place. Does something like the above library make sense to be added to nettle? regards, Nikos

1 0

Google OSS-Fuzz and Google Wycheproof for Nettle?
by Joachim Strömbergson 18 Jan '17

18 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Ran into the Google OSS-Fuzz project. The project provides the Google compute power for oss projects to run fuzzing on the code. Judging by the list of projects libraries such as GnuTLS, OpenSSL, LibSSH and Curl are being tested. Would it be worthwile to try and get Nettle accepted as a project? Has anybody looked at OSS-Fuzz for Nettle? https://github.com/google/oss-fuzz https://github.com/google/oss-fuzz/tree/master/projects Another imho interesting project Google project is Wycheproof. The project tests crypto libraries against known attacks/issues such as invalid curve attacks, biased nonces in digital signature schemes etc. Right now there are 80 tests. The code is in Java and I don't know how easy/hard it would be to connect Nettle to the test system. But at least one could look at the tests and implement the same tests for Nettle. https://github.com/google/wycheproof https://github.com/google/wycheproof/tree/master/java/com/google/security/w… Has anybody looked at Wycheproof for testing Nettle? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJYf23WAAoJEF3cfFQkIuyNKVgP/1R08TRJCYlMR2LsN3HxEJLj P6ZdksGL1A6jWHlSV7iN5UNJKWGXmF3mJ3mo4AgBZD1Xe6t1S6cpn4RkyFgc51xa +JDJgEeMhxGZptfCSjwktnoBo7T6WYZzPlw2SghD9ur6D2wiJ71K/P6LpD+3omLj BrUbaihPvRKMTPlkZi33cgjj9L1ni9LPf1I7Ir1GibtrT2NNZKZ3l2pZ5dHt7sr5 5ZtXlQZPcIlUJkpA0EUUgV5vnXMr4MxR4NFphY3xRh562ffILV0HPO+bjjPJCDo/ qbLdq0jeDXxHoIjrhUgCKWZ+03zvE+Qi+3iBiGziOS+NC92nXOnni9ehfmHrvEe5 HDBZmtO8otkU0WuUt88ovjoOKtjkvKV05gfNhwDDLSGL2NlYllAsF/13h5Ewsi2f huHdo9QPO9gUDwMDfjXt58zGmlGipju3ybSj1K9Ly/9uD1ep/yLXA/L6w2iFZ7ga XPBf0StjDLwF7yMgmhXhhhKAbV0+SgmdghG1z4D5jEVnZRhMpKN4KUs9seS8wznL XyqhWxC/swiKP1BEMbpIW9XZ3hJaMb8bKqObv5BWXscrlV7aStv9o5CFmgSeaPBr AJHXk+w6Q1dXbaVp+Tb4uhzNBVyHcLkiitQYITW8mg6SwoFclra3oh2Es2XZU1c9 h6K29UbA7UaGyum5ZDED =yz1M -----END PGP SIGNATURE-----

1 0

Subtle ABI problem with nettle_hashes
by nisse＠lysator.liu.se 13 Jan '17

13 Jan '17

The idea of the interface /* null-terminated list of digests implemented by this version of nettle */ extern const struct nettle_hash * const nettle_hashes[]; was that the size of the array isn't part of the ABI; a new Nettle version should be able to extend it with more entries, without breaking the ABI. However, I've recently learnt that it does break, in a subtle way. (See https://bugs.gentoo.org/show_bug.cgi?id=601512 and http://trofi.github.io/posts/195-dynamic-linking-ABI-is-hard.html). The problematic case is a traditional non-PIC executable linking with a nettle shared library; in this post, I care exclusively about this case. All symbol references in the executable are resolved at link time, and at load time it is mapped at a fixed address (traditionally 0, I don't know if current systems skip the first page), without any relocations. Now, if the executable links with libnettle.so, and contains a reference to the symbol nettle_hashes, the address where nettle.so is going to be mapped isn't known at link time? So how can the executable refer to it without load-time relocation of its references? The linker solves that problem using the curious relocation type R_X86_64_COPY. What the linker does is that it allocates space for a copy of the data in the BSS segment of the executable, and resolve all references to point to that copy. At the time libnettle.so is loaded, the list in the library is copied (after relocating it, but that's a minor complication in this context) to the space in the BSS. I imagine the dynamic linker also adjusts the pointers in libnettle.so's GOT table to refer to the copy rather than the original. Now the problem is that the allocation in the BSS segment, as well as the copying operation, are based on the size of the data object as recorded in the version of libnettle.so available at the time the executable was linked. If the array size is larger in the version of libnettle.so actally loaded, the copy operation is truncates it, which is particularly bad when it's NULL-terminated. So the array size, which was intended to not be part of the ABI, creeps into the ABI. So what to do about this? We have to break the ABI, but I'd prefer if we keep the API unchanged. Some alternatives: 1. Define nettle_hashesp as a constant pointer to the current nettle_hashes list, and #define nettle_hashes (*nettle_hashesp) Then nettle_hashesp will still get a R_X86_64_COPY relocation, but now the size is always a single pointer, regardless of the array size. At load time, it will be set to point directly to the list in the data segment of the loaded libnettle.so. 2. Define a function get_nettle_hashes returning a pointer to the list, and #define nettle_hashes (get_nettle_hashes()) In this case, the indirection is via a PLT entry in the executable. 3. Define the array with a size explicitly part of the ABI, extern const struct nettle_hash * const nettle_hashes[17]; Add a some reasonable number of reserved NULL entries at the end, and make an ABI break whenever we run out of reserved places and have to increase the size. We also have other public data, e.g., individual nettle_hash structs, like extern const struct nettle_hash nettle_sha256; These will also get a R_X86_64_COPY relocation if referenced (and all internal references within libnettle.so will be relocated to the copy in the executable's BSS, I guess). But that's less of a problem, since the size and layout is already part of the ABI. More problematic are the objects declared in ecc-curve.h; the size and layout of struct ecc_curve was intended to be an implementation detail, not part of the ABI, but isn't, when R_X86_64_COPY is involved. Advice appreciated. I'd also like to hear if anyone on the list knows how these things work with windows dlls. I've read sometime that exporting data (in contrast to functions) from a dll is extra tricky, but I don't remember any details. If we make any changes to fix the exported-data issues with ELF, it would be good if we could ensure that we solve any related problems for libnettle.dll too. I understand why R_X86_64_COPY is needed, but it works in a way that was pretty counter-intutive to me. The effect is, more or less, that the library's data is *statically* linked into the executable. And then initialized at load time based on the contents of the loaded library. And we then get a mix of statically linked and dynamically linked parts which might originate in different versions of the library. It would be prettier if we could force the executable to always access library data via GOT (like it works for PIC code), and never use R_X86_64_COPY. But I guess that has to be known at code generation time, and likely too late to fixup at link time, which is when we know which external data objects are defined by some shared library, and which aren't. But if anyone knows how to fix the issue in this way, I'd be delighted. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 1

Do we still need to support compilers without stdint.h?
by nisse＠lysator.liu.se 05 Jan '17

05 Jan '17

Hi, the configure macro AX_CREATE_STDINT_H and the generated nettle-stdint.h file was added more than a decade ago, when stdint.h (and c99) were somewhat new. Do we still need this? Is anyone building nettle with C compilers which don't provide stdint.h? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 1

[PATCH] memory leak fix
by Nikos Mavrogiannopoulos 03 Jan '17

03 Jan '17

Hi, The attached patch fixes a memory leak on ecdsa_verify() regards, Nikos

2 1

Language bindings question
by Ron Frederick 28 Dec '16

28 Dec '16

Hello, I recently discovered the Nettle crypto library and noticed that it has an implementation of UMAC in it, which I haven’t been able to find in most of the other popular crypto libraries out there. I was hoping to call into the UMAC functions from Python, and I see Python mentioned on the Nettle home page at http://www.lysator.liu.se/~nisse/nettle/ <http://www.lysator.liu.se/~nisse/nettle/>, but there’s no link for it down in the “Language bindings” section, and in fact many of the other links in that section seem to point at dead pages. I tried searching for Python bindings elsewhere, but haven’t had any luck so far. Does anyone know of any? Assuming there aren’t Python bindings yet, I would be tempted to try and craft my own (at least for UMAC for now). However, I’d like to be able to do it using the Python ‘ctypes’ library, and one difficulty I can see with doing that is knowing the amount of memory I should allocate for some of the structures used by this code. Specifically, for UMAC, I’d need to know the size things like “struct umac32_ctx”, “struct umac64_ctx”, “struct umac96_ctx”, and “struct umac128_ctx”. These sizes are trivial to get from C code using sizeof(), but I don’t believe there’s any good way to get them from Python using ctypes unless there’s an API call that can be made to a C function in the library which returns this information. As an example of this, libsodium provides functions like crypto_stream_chacha20_keybytes() and crypto_stream_chacha20_noncebytes() which can be called to return the size of a Chacha20 key and nonce, respectively. In the C header file, these look like: #define crypto_stream_chacha20_KEYBYTES 32U SODIUM_EXPORT size_t crypto_stream_chacha20_keybytes(void); #define crypto_stream_chacha20_NONCEBYTES 8U SODIUM_EXPORT size_t crypto_stream_chacha20_noncebytes(void); The corresponding functions in the code just return the constants defined in the header file shown above. For this UMAC example in Nettle, I could imagine similar functions which returned the value computed by sizeof() for these context structures, and also things like the UMAC key size, digest sizes, block size, and allowed nonce sizes. Has a use-case like this been considered? Is there some other way to call into Nettle from Python without writing additional glue code in C? -- Ron Frederick ronf(a)timeheart.net

3 23

Some ideas for new algorithms in Nettle
by Joachim Strömbergson 04 Dec '16

04 Dec '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! I've thought about som algorithms and constructs that I think would be useful, good to add to Nettle. We are seeing in an interest in using EC keys for both DH and DSA operations. Esp in embedded systems. One should be careful of reusing keys for more than one purpose. But for EC there seem to be some circumstances when using the keys for the two constructions does not harm each other, see: “On the Joint Security of Encryption and Signature in EMV.” Cryptology ePrint Archive, Report 2011/615, 2011. http://eprint.iacr.org/2011/6 Recently, Trevor Perrin from Openwhispersystems wrote a paper that describes how given a Curve25519 (or Curve448) keypair can reuse them in a specific DSA construction called XEdDSA. The XEdDSA is in fact a way to convert the Curve-keys in a specific way and then use them with Ed25519, Ed448 to sign or verify messages. Openwhispersystems have also code for XEd25519 on Github. I've looked at it and compared to the Curve code in Nettle. It seems that we could add this algorithm with basically a small wrapper. https://whispersystems.org/docs/specifications/xeddsa/xeddsa.pdf https://github.com/WhisperSystems/curve25519-java/blob/master/android/jni/e… https://github.com/WhisperSystems/curve25519-java/blob/master/android/jni/e… Another algorithm that I've seen been used in embedded space is the SipHash PRF/keyed hash function. It is very fast on Cortex-M devices and have low code and RAM resource requirements. If implemented in Nettle I think we should support both 64 and 128 bit digests. https://131002.net/siphash/ https://github.com/veorq/SipHash When it comes to block cipher modes, CMAC and OCB are two modes that are very interesting for embedded space. CMAC is a "better CBC-MAC" that can be/is used as KDF, MAC etc. http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf OCB is an aead construction that has seen little used until now due to licensing issues. But the licensing has been changed by Rogaway et al and there is a RFC for OCB. The cost for OCB goes asymptotically towards one cipher block operation/message block. https://www.rfc-editor.org/rfc/rfc7253.txt http://web.cs.ucdavis.edu/~rogaway/ocb/ 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? https://github.com/P-H-C/phc-winner-argon2 Finally. Since Skein was being developed, how about adding blake2? Blake2 was one of the runner ups for SHA-3 and is faster than Keccak. There is also versions of Blake2 suitable for embedded systems. https://blake2.net/ - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJYIYmnAAoJEF3cfFQkIuyN1FQQALQdER6bmnvN6fV5M2CQuVPR mMZPzm/V6DK2+WcQnB8m5X4F3t3wB6svOO0qRGJfp13+r+xftlhBR1yGhZdA/sh+ uFVEdDl71eRgg6wFlnfKB7oo1z8gVaBDiUeZFnmnB33nttXIJTS6uL+5u+c1443L 4gdylLwL/TdJzttyPUIWdiqVkqKlJCC3VX1dfvTGbXdK5NuTypZYnfESY3XI4z+m uMNsHTQtTy3JPmL0KDawPQr33ZJNYItdxLNTOae5bePMyeOTWBA52OX+SN7te/xV eFUNjMA0j7Z3haAOqAwjP5WwMwzcDbkpK1qHNuN2rbtnbqVdS8MoR66Te4y04x7t YOhtZqbV9DOVRBTNaqprHjV+4K0m6xDN6YWWOwb1fKi54mGjM6h1VvybyfKHCKpu rBRVj6uhU7gRSAQnnUhCGK4i6s0dDfS0qFikb64r9P22BtNE3KQantpdDX9M+kVH +iskZKMAqbb/i+9Yi+wm/oAnJRoaXPy44V6NXOpzlh4Leau1LeVnaesrkruo2HMd X5UvbIv7OUsbgiTt8W9fjCECP5Ub2qA1w8aV8GjiAzY27E5qiRTKoRC31uDrNymt bdwLogZmHny6kuRJADdbVcWtMaZp5gtoX53akA4obu8Ub45bA8nl+n2yHuz480+L FeU8Gr/go+MkcCRygnfW =iQua -----END PGP SIGNATURE-----

4 6

skein
by nisse＠lysator.liu.se 19 Oct '16

19 Oct '16

I've done some hacking to implement the skein hash function (one of the sha3 candidates, see https://en.wikipedia.org/wiki/Skein_%28hash_function%29). Development is done on the "skein" branch of the repo. At low-level it has some similarities to salsa20 and chacha: An input block is mangled in a perfectly invertible way using only add, xor and rotation, followed by an addition of the original input, which destroys invertibility. And then this primitive is used to construct a hash function. I've implemented skein256, both for portable C and x86_64 assembly. The current implementation is written for small footprint in both code and data, it could perhaps be made a little faster with more unrolling. On x86_64, it's slightly slower than sha1, slightly faster than sha512, and considerably faster than sha256 and sha3 (and these relations are likely to be similar on all platforms with a reasonable number of 64-bit registers). Performance is a bit behind the numbers reported in the skein paper http://www.skein-hash.info/sites/default/files/skein1.3.pdf; not sure if the difference is due to unrolling, different benchmarking machines, or additional implementation tricks. (On my current x86_64 machines, benchmarking using the nettle-enchmark is not very accurate, numbers vary quite a bit from one run to the next). And it's a pity there's no easy way to rotate different pieces of an xmm register by different counts; that makes it hard to get any advantage of the parts of the skein/threefish round which do fit SIMD. So the design is a lot less SIMD-friendly than chacha. skein512 is in progress; there it's not possible to fit all inputs in registers (unless one can make good use of SIMD registers in some way), and I haven't yet figured out a good way to organize it for performance. Skein can be used in additional ways than a plain hash function, e.g., as a mac, or key derivation function. I don't plan to implement such additional skein features until there's some clear use case for them. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-3.3
by nisse＠lysator.liu.se 02 Oct '16

02 Oct '16

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This is mainly a bug fix release. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. NEWS for the Nettle 3.3 release This release fixes a couple of bugs, and improves resistance to side-channel attacks on RSA and DSA private key operations. Changes in behavoir: * Invalid private RSA keys, with an even modulo, are now rejected by rsa_private_key_prepare. (Earlier versions allowed such keys, even if results of using them were bogus). Nettle applications are required to call rsa_private_key_prepare and check the return value, before using any other RSA private key functions; failing to do so may result in crashes for invalid private keys. As a workaround for versions of Gnutls which don't use rsa_private_key_prepare, additional checks for even moduli are added to the rsa_*_tr functions which are used by all recent versions of Gnutls. * Ignore bit 255 of the x coordinate of the input point to curve25519_mul, as required by RFC 7748. To differentiate at compile time, curve25519.h defines the constant NETTLE_CURVE25519_RFC7748. Security: * RSA and DSA now use side-channel silent modular exponentiation, to defend against attacks on the private key from evil processes sharing the same processor cache. This attack scenario is of particular relevance when running an HTTPS server on a virtual machine, where you don't know who you share the cache hardware with. (Private key operations on elliptic curves were already side-channel silent). Bug fixes: * Fix sexp-conv crashes on invalid input. Reported by Hanno Böck. * Fix out-of-bounds read in des_weak_p. Fixed by Nikos Mavrogiannopoulos. * Fix a couple of formally undefined shift operations, reported by Nikos Mavrogiannopoulos. * Fix compilation with c89. Reported by Henrik Grubbström. New features: * New function memeql_sec, for side-channel silent comparison of two memory areas. Miscellaneous: * Building the public key support of nettle now requires GMP version 5.0 or later (unless --enable-mini-gmp is used). * Filenames of windows DLL libraries now include major number only. So the dll names change at the same time as the corresponding soname on ELF platforms. Fixed by Nikos Mavrogiannopoulos. * Eliminate most pointer-signedness warnings. In the process, the strings representing expression type for sexp_interator functions were changed from const uint8_t * to const char *. These functions are undocumented, and it doesn't change the ABI on any platform I'm aware of. The shared library names are libnettle.so.6.3 and libhogweed.so.4.3, with sonames still libnettle.so.6 and libhogweed.so.4. It is intended to be fully binary compatible with nettle-3.1. https://ftp.gnu.org/gnu/nettle/nettle-3.3.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.3.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.3.tar.gz Happy hacking, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 7

use gitlab's shared runners
by Nikos Mavrogiannopoulos 14 Sep '16

14 Sep '16

Hi, This patch converts nettle's CI to use gitlab's infrastructure. Red Hat's specific runners currently used for CI will be phased out, so it makes sense to switch to gitlab.com shared infrastructure. An other advantage is that more (Linux) systems can be checked due to the fact that this CI is based on docker. An example run can be seen at: https://gitlab.com/gnutls/nettle/pipelines/4146073 regards, Nikos

3 4

plan for 3.3
by Nikos Mavrogiannopoulos 06 Sep '16

06 Sep '16

Hi, Some comments on the 3.3, plan: > + Add larger "safe" curves, e.g., M-383, curve41417, curve448 and > + E-521. I think curve448 should be prioritized over anything else since it seems to be the only thing being standardized at the moment by CFRG: https://tools.ietf.org/html/rfc7748 For password hashing (pbkdf2), it may also worth considering to add support for argon2,which seems to be the only password hashing algorithm coming out of a competition: https://password-hashing.net/ > Side-channel silent mem_equalp. Do you mean a function with run time independent of its input values? I have such a function at gnutls: https://gitlab.com/gnutls/gnutls/blob/master/lib/safe-memfuncs.c#L70 regards, Nikos

2 3

TLS 1.3 in gnutls
by Nikos Mavrogiannopoulos 05 Sep '16

05 Sep '16

Hi, I've tried to make a rough sketch of the requirements needed to support TLS 1.3 in gnutls. I've split the task in sub-tasks on [0]. Some need to be handled in gnutls and some need to be handled in nettle. Do you think I've missed something, or there are tasks that can be further split? About the nettle additions, is there anyone already working or willing to work on these? On the gnutls part is there anyone already working or willing to work on the missing parts? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/milestones/8

2 2

display code coverage
by Nikos Mavrogiannopoulos 05 Sep '16

05 Sep '16

Hi, The attached patch uses lcov to display the code coverage of the test suite. It uses ax_code_coverage.m4 which assumes automake, so this patch modifies it to be able to work. This is a preliminary patch to demo the functionality, as I haven't gone through all the automake- related variables. regards, Nikos

2 1

char vs uint8_t
by nisse＠lysator.liu.se 03 Sep '16

03 Sep '16

I'd like to eliminate pointer-signedness warnings. I'm afraid some ugly casts will have to be involved, since most functions work with uint8_t, and at least test code needs to pass literal strings, of type char *. I have one question, on the ascii-armor funtions: Would ie make sense to change the type of ascii inputs and outputs to char? I.e., size_t base64_encode_update(struct base64_encode_ctx *ctx, - uint8_t *dst, + char *dst, size_t length, const uint8_t *src); and similarly for all related functions. It would be an API change but not an ABI change for any ABI spec I'm aware of. What do you think? So the input to encoding is an octet string (uint8_t), and the output is a string of plain char. And vice versa for decoding functions. Also applies to the type arguments for sexp_iterator_check_type, sexp_iterator_check_types and sexp_iterator_assoc, currently using uint8_t. They are usually called with literal ascii strings, so it would make some sense to type as char rather than uint8_t. (I don't think these are used much by any application except lsh and libspki). And no matter how things are typed, I wouldn't expect nettle to work out of the box on platforms where char and uint8_t are of different size, or where string literals use a non-asciii character set. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 3

Using mpz_powm_sec
by nisse＠lysator.liu.se 08 Aug '16

08 Aug '16

I'm considering the below patch, making use of the side-channel silent mpz_powm_sec function. The idea is to make the RSA and DSA code less vulnerable to side-channel attacks. Exponentiation routines typically build a small table of powers at run time, and then look up exponent bits in the table, a few bits at the time. This table lookup may leak information about the exponent bits (which in the case of RSA and DSA are secret) to an attacker running other processes on the same physical machine. mpz_powm_sec uses a slower table-lookup function, which for each lookup does a sequential read of the entire table. Some caveats: * The CRT code used for RSA signing uses other functions which may leak, in particular division functions with branches depending on secret data. * Since we still use the mpz interface rather than the mpn interface in gmp, the exponents use a normalized size field (so top limb is non-zero). This might still leak information about the top exponent bits. * The patch drops support for GMP versions older than GMP-5.0, relased in 2010. * Mini-gmp builds don't try to be side-channel silent, they will use a #define mpz_powm_sec mpz_powm. * I haven't yet had time to do proper benchmarks. Signing should get a bit slower, but I don't know how much. Despite not plugging *all* potential leaks in the RSA code, I think the simple change to use use mpz_powm_sec should make attacks using the cache side-channel considerably more difficult. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 27

[patch] Nettle add missing cflags to some objects
by Tomas Chvatal 04 Aug '16

04 Aug '16

Hello, I noticed that some objects are compiled without cflags. See attached patch that fixes the situation. :) Cheers Tom

3 4

gitlab merge requests
by Nikos Mavrogiannopoulos 07 Jul '16

07 Jul '16

Hi, The gitlab pages on git.lysator.liu.se seem like they are not actively being followed. Although pull and merge requests are the norm for some, if they are not followed, it may make more sense to turn off from the admin interface the merge request option (btw. also the builds option because it tries to build although no runners are configured). Some merge requests in gitlab which look reasonable: https://git.lysator.liu.se/nettle/nettle/merge_requests/1 https://git.lysator.liu.se/nettle/nettle/merge_requests/4 (btw. I have an automatically updated mirror of nettle at https://github.com/gnutls/nettle ) Not sure about the usefulness of: https://git.lysator.liu.se/nettle/nettle/merge_requests/2 https://git.lysator.liu.se/nettle/nettle/merge_requests/3 (this seems identical to 4) regards, Nikos

1 0

Porting openssl code to nettle
by Aaron Boxer 31 May '16

31 May '16

Hello! I am porting some openssl code to nettle. It involves working with SHA1 keys. What would people recommend as a guide to doing this port? I know very little about cryptography. The code can be found here: https://github.com/GrokImageCompression/asdcplib/blob/master/src/KM_prng.cpp Thanks so much, Aaron

2 10

Curve25519 and RFC 7748
by nisse＠lysator.liu.se 02 May '16

02 May '16

Hi, Nikos pointed out to me that there's a slight difference between curve25519 as implemented by Nettle and the spec in RFC 7748. As far as I see, the difference is that RFC 7748 says that bit 255 of an encoded x coordinates is ignored. Or more precisely, the high bit of the 31:st octet in the x input string is cleared before convertion into an integer. While nettle's curve25519_mul includes it in the computation, with the usual wrap-around, 2^255 = 19 (mod p). I don't see any difference in handling scalars. Do you agree? So I'm considering this change, diff --git a/curve25519-mul.c b/curve25519-mul.c index adb20cb..f5127d7 100644 --- a/curve25519-mul.c +++ b/curve25519-mul.c @@ -72,7 +72,11 @@ curve25519_mul (uint8_t *q, const uint8_t *n, const uint8_t *p) itch = ecc->p.size * 12; scratch = gmp_alloc_limbs (itch); + /* Note that 255 % GMP_NUMB_BITS == 0 isn't supported, so x1 always + holds at least 256 bits. */ mpn_set_base256_le (x1, ecc->p.size, p, CURVE25519_SIZE); + /* Clear bit 255, as required by RFC 7748. */ + x1[255/GMP_NUMB_BITS] &= ~((mp_limb_t) 1 << (255 % GMP_NUMB_BITS)); /* Initialize, x2 = x1, z2 = 1 */ mpn_copyi (x2, x1, ecc->p.size); I wouldn't expect any problems from this, its a corner case with input values which are arguably invalid. The motivation in the RFC, as I understand it, is to leave open for protocols to use the top bit for their own, without bothering to clear it before invoking curve25519. Which at first seems a bit silly, but there's some value in not leaving corner cases implementation defined, and it would maybe have been even more silly to require that implementations do wraparound of that improper high bit. This change would also need some updates of testcases and documentation. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

dll file names
by Nikos Mavrogiannopoulos 30 Mar '16

30 Mar '16

Hello, The attached patch corrects the name used for the windows dlls. With the current naming, it is not possible to update an existing version of nettle by dropping the new files in place and the patch fixes that. regards, Nikos

3 5

mini-gmp builds enhancements
by Nikos Mavrogiannopoulos 18 Mar '16

18 Mar '16

The attached patches fix compilation issues with mini-gmp, add a gitlab build rule, and prevent the symbols defined in gmp-glue.h from being exported into nettle's ABI. The latter was to avoid abidiff differences to hogweed's ABI when built with different gmp versions. For that I renamed the gmp-glue _nettle_* symbols to _inettle_*. regards, Nikos

2 4

patch to use gitlab runners with libasan and libubsan
by Nikos Mavrogiannopoulos 15 Mar '16

15 Mar '16

Hello, I've now completed enabling the undefined sanitizer for gnutls, and may be a good idea to use it for nettle to. The following patch enables running the test suite of nettle under libasan (to detect any invalid memory accesses/writes), and the undefined sanitizer. I've run a test build, and the libasan build succeeds but the libubsan builds fail: https://gitlab.com/gnutls/nettle/builds/773956 Its complaints are not that critical for the targetted platforms but may be nice not to rely on undefined behavior. regards, Nikos

3 2

abort / assert issues in sexp-conv
by Hanno Böck 16 Feb '16

16 Feb '16

Hi, I did a quick fuzzing test of the command line tools coming with nettle. echo "]"|sexp-conv will cause an abort call and echo "{MiM}"|sexp-conv causes an assert: sexp-conv: /var/tmp/portage/dev-libs/nettle-3.2/work/nettle-3.2/tools/input.c:128: sexp_input_start_coding: Assertion `!input->coding' failed. Not sure how relevant these tools are, but usually abort/assert calls are debugging tools for situations in a software that should never happen on normal operations. -- Hanno Böck https://hboeck.de/ mail/jabber: hanno(a)hboeck.de GPG: BBB51E42

2 2

backporting ecc patches
by Nikos Mavrogiannopoulos 09 Feb '16

09 Feb '16

Hello Niels, Do you plan a backport of the carry propagation fix in secp384 [0] for nettle 2.7.1? My limited understanding of the 3.2 assembly file wouldn't work out of the box in 2.7 due to the change from ecc_curve to ecc_modulus. The fix for the secp256r1 issue [1] looks quite trivial to backport if p->m is replaced by ecc->p. Is my understanding correct? regards, Nikos [0]. https://git.lysator.liu.se/nettle/nettle/commit/fa269b6ad06dd13c90 1dbd84a12e52b918a09cd7 [1]. https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985 e3872e4550137209e3ce4d

3 3

cross compiling nettle-3.2 for armv7 on linux
by Girish Kumar 07 Feb '16

07 Feb '16

Hi All, I am cross compiling nettle-3.2 for armv7 on linux. But I am getting following error. Could you please help me on this nettle_deps = $(shell find $(LTOP)/nettle-3.2 -type f) $(OBJS)/nettle/nettle.configured: $(nettle_deps) @rm -rf $(OBJS)/nettle; @mkdir -p $(OBJS)/nettle; @cd $(OBJS)/nettle;\ declare -x PATH=$(CCPATH):$(PATH);\ declare -x ac_cv_func_malloc_0_nonnull="yes";\ declare -x ac_cv_func_realloc_0_nonnull="yes";\ declare -x CFLAGS="$(PLATFORM_CFLAGS) ";\ declare -x LDFLAGS="$(PLATFORM_LDFLAGS) -L$(CROSSLIBS) -L$(BUILT_LIBS)";\ declare -x CPPFLAGS="$(PLATFORM_CPPFLAGS) -I$(CROSSINCS) -I$(BUILT_INCLUDES) ";\ $(LTOP)/nettle-3.2/configure --prefix=$(BUILT_BASE) --host=$(CCPREFIX) --disable-static&> $(OBJS)/nettle/configure.out @touch $(OBJS)/nettle/nettle.configured $(RAMDISK_LIB)/nettle.so: $(OBJS)/nettle/nettle.configured @cd $(OBJS)/nettle;\ declare -x HOSTCC=`which gcc`;\ declare -x PATH=$(CCPATH):$(PATH);\ declare -x CFLAGS="$(PLATFORM_CFLAGS) ";\ declare -x LDFLAGS="$(PLATFORM_LDFLAGS) -L$(CROSSLIBS) -L$(BUILT_LIBS)";\ declare -x CPPFLAGS="$(PLATFORM_CPPFLAGS) -I$(CROSSINCS) -I$(BUILT_INCLUDES) ";\ $(MAKE) &> $(OBJS)/nettle/make.out;\ $(MAKE) install &> $(OBJS)/nettle/install.out checking build system compiler gcc... no checking build system compiler cc... no checking build system compiler c89... no checking build system compiler c99... no configure: error: Cannot find a build system compiler make[1]: *** [/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/nettle/nettle.configured] Error 1 make[1]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps' make: *** [tps-build] Error 2 + set +x My make file changes. Please let me know if anything is wrong. Regards, Girish

2 2

ANNOUNCE: Nettle-3.2
by nisse＠lysator.liu.se 28 Jan '16

28 Jan '16

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This is mainly a bug fix release, with few new features. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. NEWS for the Nettle 3.2 release Bug fixes: * The SHA3 implementation is updated according to the FIPS 202 standard. It is not interoperable with earlier versions of Nettle. Thanks to Nikos Mavrogiannopoulos. To easily differentiate at compile time, sha3.h defines the constant NETTLE_SHA3_FIPS202. * Fix corner-case carry propagation bugs affecting elliptic curve operations on the curves secp_256r1 and secp_384r1 on certain platforms, including x86_64. Reported by Hanno Böck. New features: * New functions for RSA private key operations, identified by the "_tr" suffix, with better resistance to side channel attacks and to hardware or software failures which could break the CRT optimization. See the Nettle manual for details. Initial patch by Nikos Mavrogiannopoulos. * New functions nettle_version_major, nettle_version_minor, as a run-time variant of the compile-time constants NETTLE_VERSION_MAJOR and NETTLE_VERSION_MINOR. Optimizations: * New ARM Neon implementation of the chacha stream cipher. Miscellaneous: * ABI detection on mips, with improved default libdir location. Contributed by Klaus Ziegler. * Fixes for ARM assembly syntax, to work better with the clang assembler. Thanks to Jukka Ukkonen. * Disabled use of ifunc relocations for fat builds, to fix problems most easily triggered by using dlopen RTLD_NOW. The shared library names are libnettle.so.6.2 and libhogweed.so.4.2, with sonames still libnettle.so.6 and libhogweed.so.4. It is intended to be fully binary compatible with nettle-3.1. https://ftp.gnu.org/gnu/nettle/nettle-3.2.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.2.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.2.tar.gz Happy hacking, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Nettle-3.2 plans
by nisse＠lysator.liu.se 28 Jan '16

28 Jan '16

Now I think the documentation of the new RSA tr functions is in reasonable shape, and I'd like to get a release out real soon now. I've put a release candidate at https://www.lysator.liu.se/~nisse/archive/nettle-3.2rc1.tar.gz, and I've updated the release planning at https://www.lysator.liu.se/~nisse/nettle/plan.html. I've spent the day doing tests on various emulated systems. The ARM and PPC emulators have completed the tests with no issues, MIPS and M68K emulators still working hard. Currently, I'm doing tests on gnu/linux and freebsd (the sparc solaris systems I used to do some testing on have been powered down). If no last minute problems are discovered, I plan to make the release earliest on Wednesday evening (January 27). All testing is highly appreciated. In particular, if Mac, Windows, or some more obscure systems are important to you, now is the time to test. As a reminder, non-GNU make programs are not really supported. Review of the NEWS file and the new RSA material in the manual would also be very nice. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs