nettle-bugs

nettle-bugs@lists.lysator.liu.se

2219 discussions

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 20 Oct '16

20 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 07 Sep '16

07 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 04 Sep '16

04 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

Jump to page:

2026

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