nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

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

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