nettle-bugs April 2018

nettle-bugs@lists.lysator.liu.se

3 participants
4 discussions

[PATCH 0/8] Implement Curve448 ECDH and Ed448
by Daiki Ueno 02 Jan '20

02 Jan '20

Hello, This patch series implements the Curve448 Diffie-Hellman protocol (RFC 7748) and the Ed448 signature scheme (RFC 8032). Although I tried to make it as close as possible to the Curve25519 and Ed25519 implementations, I had to add a few special cases, namely: - for Curve448, eccdata directly calculates points on the Edwards curve instead of the equivalent Montgomery curve - untwisted versions of ecc_add_eh* and ecc_dup_eh are added - the point decoding for Ed448 uses a different formula to recover u and v Also, optimized implementation of modular reduction is currently missing, which is beyond my expertise. I would appreciate any suggestions regarding that. The patches are also available on: https://gitlab.com/dueno/nettle/commits/wip/dueno/ed448 Thanks to Hubert Kario and Nikos Mavrogiannopoulos for initial reviews. Daiki Ueno (8): ecc-mul-test: Fix mpn_cmp calls eccdata: Emit correct ecc_Bmodq_shifted for curve448 eccdata: Redirect ecc_point_out to given stream, instead of stderr ecc: Add add_hh and dup members to ecc_curve ecc-eh-to-a, eddsa-sign: Parameterize hard-coded value Implement curve448 primitives Implement SHAKE128/256 functions Implement Ed448 signature scheme .gitignore | 1 + Makefile.in | 18 +- curve448-eh-to-x.c | 73 + curve448-mul-g.c | 74 + curve448-mul.c | 148 + curve448.h | 58 + ecc-192.c | 5 + ecc-224.c | 5 + ecc-25519.c | 5 + ecc-256.c | 5 + ecc-384.c | 5 + ecc-448.c | 273 ++ ecc-521.c | 5 + ecc-add-eh.c | 74 +- ecc-add-ehh.c | 77 +- ecc-dup-eh.c | 55 +- ecc-eh-to-a.c | 4 +- ecc-internal.h | 57 +- ecc-mul-a-eh.c | 12 +- ecc-mul-g-eh.c | 4 +- ecc-point-mul-g.c | 7 +- ecc-point-mul.c | 2 +- ecc-point.c | 15 + eccdata.c | 183 +- ecdsa-keygen.c | 4 +- ed25519-sha512-sign.c | 15 + ed448-shake256-pubkey.c | 60 + ed448-shake256-sign.c | 92 + ed448-shake256-verify.c | 66 + eddsa-compress.c | 11 +- eddsa-decompress.c | 15 +- eddsa-expand.c | 20 +- eddsa-hash.c | 35 + eddsa-pubkey.c | 2 +- eddsa-sign.c | 18 +- eddsa-verify.c | 16 +- eddsa.h | 24 + examples/ecc-benchmark.c | 1 + nettle-internal.h | 2 +- nettle-meta-hashes.c | 2 + nettle-meta.h | 2 + nettle.texinfo | 152 +- sha3.c | 13 + sha3.h | 56 + shake128-meta.c | 42 + shake128.c | 84 + shake256-meta.c | 42 + shake256.c | 84 + testsuite/.test-rules.make | 12 + testsuite/Makefile.in | 5 +- testsuite/curve448-dh-test.c | 100 + testsuite/ecc-add-test.c | 48 +- testsuite/ecc-dup-test.c | 12 +- testsuite/ecc-mul-a-test.c | 6 +- testsuite/ecc-mul-g-test.c | 6 +- testsuite/ecdh-test.c | 16 +- testsuite/ecdsa-keygen-test.c | 16 + testsuite/ed448-test.c | 240 ++ testsuite/eddsa-compress-test.c | 137 +- testsuite/eddsa-sign-test.c | 66 +- testsuite/eddsa-verify-test.c | 49 +- testsuite/meta-hash-test.c | 2 + testsuite/shake.awk | 14 + testsuite/shake128-test.c | 6183 +++++++++++++++++++++++++++++++++++++++ testsuite/shake256-test.c | 6183 +++++++++++++++++++++++++++++++++++++++ testsuite/testutils.c | 57 +- 66 files changed, 14976 insertions(+), 199 deletions(-) create mode 100644 curve448-eh-to-x.c create mode 100644 curve448-mul-g.c create mode 100644 curve448-mul.c create mode 100644 curve448.h create mode 100644 ecc-448.c create mode 100644 ed448-shake256-pubkey.c create mode 100644 ed448-shake256-sign.c create mode 100644 ed448-shake256-verify.c create mode 100644 shake128-meta.c create mode 100644 shake128.c create mode 100644 shake256-meta.c create mode 100644 shake256.c create mode 100644 testsuite/curve448-dh-test.c create mode 100644 testsuite/ed448-test.c create mode 100755 testsuite/shake.awk create mode 100644 testsuite/shake128-test.c create mode 100644 testsuite/shake256-test.c -- 2.13.3

2 35

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

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 April 2018