nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2193 discussions

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

17 Jun '18

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 7871d843168c..42a97e63d6b6 100644 --- a/bignum.h +++ b/bignum.h @@ -68,11 +68,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, @@ -92,6 +100,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.17.1

2 2

[PATCH] Fix quoting in autoconf ifunc test
by Dmitry Eremin-Solenikov 17 Jun '18

17 Jun '18

* aclocal.m4 (NETTLE_CHECK_IFUNC): fix quoting so that AC_LINK_IFELSE/AC_TRY_LINK is defined outside of this test. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> --- aclocal.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index 783dbc492b5c..772f68e8eb9d 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -650,7 +650,7 @@ AC_DEFUN([NETTLE_CHECK_IFUNC], [AC_REQUIRE([AC_PROG_CC]) AC_CACHE_CHECK([for ifunc support], nettle_cv_link_ifunc, - AC_LINK_IFELSE([AC_LANG_PROGRAM([ + [AC_LINK_IFELSE([AC_LANG_PROGRAM([ static int foo_imp(int x) { @@ -671,7 +671,7 @@ int foo (int x) __attribute__ ((ifunc("foo_resolv"))); ])], [nettle_cv_link_ifunc=yes], -[nettle_cv_link_ifunc=no])) +[nettle_cv_link_ifunc=no])]) AH_TEMPLATE([HAVE_LINK_IFUNC], [Define if compiler and linker supports __attribute__ ifunc]) if test "x$nettle_cv_link_ifunc" = xyes ; then AC_DEFINE(HAVE_LINK_IFUNC) -- 2.17.1

2 2

[Dominyk Tiller] Fwd: Xcode/CLT 10+ Patch
by nisse＠lysator.liu.se 14 Jun '18

14 Jun '18

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

1 0

API for new AEAD modes
by Nikos Mavrogiannopoulos 31 May '18

31 May '18

Hi, As it is now AEAD ciphers in nettle are supported with their own API. AES-CCM provides: ccm_aes128_set_key ccm_aes128_set_nonce ccm_aes128_update ccm_aes128_encrypt ccm_aes128_decrypt ccm_aes128_digest ccm_aes128_encrypt_message ccm_aes128_decrypt_message AES-GCM: gcm_aes128_set_key gcm_aes128_update gcm_aes128_set_iv gcm_aes128_encrypt gcm_aes128_decrypt gcm_aes128_digest chacha-poly1305: chacha_poly1305_set_key chacha_poly1305_set_nonce chacha_poly1305_update chacha_poly1305_encrypt chacha_poly1305_decrypt chacha_poly1305_digest ccm_aes128_set_nonce takes different parameters from the chacha and gcm equivalent function. Furthermore the AEAD modes for block ciphers include an abstract layer which can be re-used of other ciphers. For example the GCM mode abstraction is re-used for camellia as well. So overall there is a kind of "abstract" API followed with the set_key, set_nonce, update, encrypt/decrypt, however these have not always the same parameters as in the CCM case. I'm checking the AES-SIV-CMAC mode which cannot even be put in that abstraction as the MAC in SIV is the IV and thus the MAC-style API doesn't really suit it. My understanding is that AEAD modes according to RFC5116 need to have 4 inputs: key, nonce, associated data, plaintext so the CCM encrypt and decrypt message seem to be the closer to that API. Would it make sense to standardize on these, and only provide that API for AEAD modes? The reason I'm asking is because SIV could benefit of a very custom API as well because it can take advantage of multiple associated data, but in the end I believe AEAD is about simplicity. Providing a unique API per AEAD cipher seems to me quite contradictory to that goal. regards, Nikos

4 6

https://git.lysator.liu.se/ seems to be offline...
by Tim Rühsen 14 Apr '18

14 Apr '18

1 0

symbol versioning update
by Nikos Mavrogiannopoulos 03 Apr '18

03 Apr '18

Hi, When we initially introduced symbol versioning in nettle we bundled all symbols from the library in a single version. That means that new symbols added to a release like nettle_get_hashes() may cause issues like this: https://bugzilla.redhat.com/show_bug.cgi?id=1549190 The underlying issue is in rpm-based systems which detect which symbols exist in which library version based on the version. That way, when a dependency is tracked, the version with the right symbol will be retrieved. Debian-based systems work differently so that shouldn't affect it. To address these problems in gnutls, I follow these additional rules in to having a map file: https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md#symbol-and-lib… which in turn comes from libvirt: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ That of course adds overhead on releases. nettle doesn't necessarily need to follow that process, I send that issue in order to spark discussion on whether that's desirable to have. regards, Nikos

3 6

What should nettle-3.5 be like?
by nisse＠lysator.liu.se 27 Mar '18

27 Mar '18

I used to think that next Nettle release should be focused on performance and add a few more features, no incompatible changes. But since the gcm changes breaks gnutls (fix in https://gitlab.com/gnutls/gnutls/commit/176aa191380e5d63a981f08f537deffdd78…), best way to reduce damage might be to bump the nettle soname. And if we do that, there are a couple of other things that could be done at the same time. Some changes to consider: 1. Remove the the symbols nettle_hashes and nettle_secp_384r1 and friends from the interface. They should be renamed with leading underscore. Important to be able to merge ed448 work without breaking the abi again. 2. Delete the old aes_* interface, in favor of aes128_, aes192_* and aes256_*. This could help aesni performance, where it might be nice with separately completely unrolled code for each key size. 3. Change struct nettle_aead to be more message-oriented. 4. Hide undocumented and internal symbols (the ones with leading underscore) more. Move declarations to internal uninstalled headers, possible tweak linker script to not expose at all in the shared library. 5. Revamp hmac and underlying hash functions with a separate state struct. Probably low priority, but it is a bit silly that, e.g., hmac_sha512_ctx includes three 128-byte large block buffers. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

5 22

Re: [PATCH 1/3] Add arm endianness-aware assembly infrastructure
by nisse＠lysator.liu.se 25 Mar '18

25 Mar '18

Michael Weiser <michael.weiser(a)gmx.de> writes: > Introduce m4 macros to conditionally handle differences of little- and > big-endian arm in assembler code. This and the next two patches now merged to master-updates for some final testing. At the moment, I'm only able to test that plain little-endian arm is still working. Thanks! /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 1

mailing list archives
by Nikos Mavrogiannopoulos 20 Mar '18

20 Mar '18

Hi, On certain occasions I was trying to link to posts in that list however it seems that the official archives are not updated on a reasonable frequency. For example the current archives [0] were last updated on January 4. Is it possible to increase the archive generation frequency to weekly or sooner? regards, Nikos [0]. https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/date.html

2 3

Efficient ED25519 on microcontrollers
by nisse＠lysator.liu.se 13 Mar '18

13 Mar '18

This is vaguely related to Nettle, but may be of interest to some people on the list. I've tried to summarize how to implement ed25519 efficiently on low-end hardware, with MSP430 as a concrete example. Most of the tricks are used by Nettle's implementation as well. Not sure if it would make any sense to try to port Nettle to such systems, but might be doable if there's interest in it. I would imagine that the need for good crypto on cheap devices is only going to increase in coming years. See https://www.lysator.liu.se/~nisse/misc/ed25519-msp430.html. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Jump to page:

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