nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

curve25519 and eddsa
by nisse＠lysator.liu.se 19 Mar '15

19 Mar '15

I've just pushed some documentation for the curve25519 and eddsa functions. This raises a few questions on the current interfaces. 1. Should ecc-curves.h really declare nettle_curve25519? Its' not needed for any of the documented functions, except for obscurities like doing ecdsa (not eddsa) over the curve. It could be moved to ecc-internal, or be marked as internal in some other way. Perhaps renaming to _nettle_ed25519 would be appropriate. 2. curve25519_mul should be changed to have a void return type (an earlier implementation failed for inputs which didn't correspond to points on the curve, but instead were points on its twist). But the current implementation, using the Montgomery ladder, doesn't care and computes a well defined result for all inputs. 3. struct ed25519_private_key and struct ed25519_public_key include compile-time constant limb arrays. At least for the public key, this will imply an ABI break if/when we switch to a base 2^51 representations for GF(2^255 - 19). So maybe switch to dynamic allocation for struct ed25519_public_key, or both structs? 4. There's no function to generate eddsa key pairs. To generate a private key, use a random 32-octet string. To get the corresponding public key, one can call ed25519_set_private_key, and copy the pub element of the struct. This needs some additional documentation or maybe some additional function. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 12

patch: define API version number
by Nikos Mavrogiannopoulos 19 Mar '15

19 Mar '15

Hello, This patch adds a definition in nettle-meta.h with nettle's version number. That way applications can be easily modified to support both the 2.7 and the 3.x API. I didn't add for hogweed because it didn't seem to make sense, the API version is fully determined by nettle only. regards, Nikos

2 8

patch: added missing dist files
by Nikos Mavrogiannopoulos 19 Mar '15

19 Mar '15

1 0

test failures on powerpc64le-redhat-linux
by Martin Sebor 17 Mar '15

17 Mar '15

Running Nettle 3.0 tests on a powerpc64le RHEL 7.1 box shows the two failures below. The cause is in the second definition of the HAVE_NATIVE_64_BIT configuration macro: $ grep HAVE_NATIVE_64_BIT config.* config.h:# define HAVE_NATIVE_64_BIT 1 config.h:# define HAVE_NATIVE_64_BIT (SIZEOF_LONG * CHAR_BIT >= 64) The macro relies on the CHAR_BIT macro being defined at the point of its expansion. Uses of HAVE_NATIVE_64_BIT of the form #if !HAVE_NATIVE_64_BIT in files that don't include <limits.h> (and thus don't have the CHAR_BIT macro defined) end up compiling the conditional blocks that are intended to be included only when the target has no native support for 64 bit arithmetic. One such file that comes into play in the failing tests is camellia-absorb.c. Since powerpc64le obviously does have such support, the code is unnecessary and, as it turns out, introduces errors. Once <limits.h> is included all of Nettle's tests pass even on powerpc64le-redhat-linux. Martin ... Encrypt failed: Input: 0123456789abcdef fedcba9876543210 Output: df51fc645013f77c 25c472e2871f742a Expected: 6767313854966973 0857065648eabe43 /src/nettle-3.0/run-tests: line 57: 46381 Aborted "$1" $testflags FAIL: camellia ... Assert failed: /src/nettle-3.0/testsuite/testutils.c:513: MEMEQ(digest->length, buffer, digest->data) /src/nettle-3.0/run-tests: line 57: 49811 Aborted "$1" $testflags FAIL: gcm ... ==================== 2 of 55 tests failed ====================

2 1

memeql_sec
by nisse＠lysator.liu.se 14 Mar '15

14 Mar '15

I think there's only one sensitive use of memcmp within nettle, and that's the tag comparison in ccm_decrypt_message. I've now written a private function memeql_sec to do that comparison in a more side-channel silent fashion. static int memeql_sec (const void *a, const void *b, size_t n) { volatile const unsigned char *ap = (const unsigned char *) a; volatile const unsigned char *bp = (const unsigned char *) b; volatile unsigned char d; size_t i; for (d = i = 0; i < n; i++) d |= (ap[i] ^ bp[i]); return d == 0; } The idea is to avoid leaking (via timing or memory access patterns) the location of the first difference. Information that a guess for a forged MAC tag matches some characters of the correct MAC can be used to attack the MAC key, in particular for MAC algorithms with linear structure such as gcm and poly1305 (which is why chacha-poly1305 uses a new poly1305 key for each message, and why one shouldn't use gcm with short authentication tags). memeql_sec is a bit similar to http://nacl.cr.yp.to/verify.html. Now, applications using nettle are likely doing a lot of similar comparisons on hash and hmac digests. So it would be good to make this function public. But then I'd need to decide on 1. A good name. 2. A suitable headerfile to declare it in. It would make some sense to group it together with memxor, but memxor.h isn't a good name for that header file. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 5

Please add base-64 URL-safe alphabet
by Amos Jeffries 10 Feb '15

10 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RFC 4648 (https://tools.ietf.org/html/rfc4648) standardizes two Base-64 alphabets. Nettle currently only supports the traditional base-64 alphabet from section 4. There is growing use amongst new protocol definitions and extensions, particularly in the HTTP area for the URL-safe extension alphabet instead of the classical Base-64 alphabet. The attached patch implements a proposed API/ABI extension adding support for RFC 4648 section 5 "Base 64 Encoding with URL and Filename Safe Alphabet" External code simply calls the init() function relevant to the alphabet it is needing to encode/decode with. The library internally uses the context to select which lookup table to use for later base64 function calls. The base64_encode_raw() and base64_encode_group() functions which do not use contexts are left untouched for now. Amos Jeffries Treehouse Networks Ltd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUiXerAAoJELJo5wb/XPRjPxEIAJGMXNF0H84kJntKpe1idimr +x7/xg55GJ2sWEBAbVIHvKvjFZoBIeqNmPeeK+yrqMdA+dtALA37AuezqhiNBtuj YfGd/DyRvys2O2bQ4XNRHxj6zGQU6tlRHHZzSnWp9ywwN4xk/zfNc5JM0EKYqiuu 8crNPzQxP91N33gkdi9LrOkAA8v+/bTYJgTrT46D/2Ut+8ECAcpjS5jwsJiljETu uqO50QlhqGC3ZsHKs1kYnjrbl1Peiqw/b/srEnY3shfS9MKrTYe3qLOsvU5CQpnD A7e8w/SW716D0s4t0SGf85WvUnS6UvDTfAdm3EXAPKNU8PaYpK9D8izq8kgxCP4= =NgGG -----END PGP SIGNATURE-----

4 15

nettle-3.1 loose ends
by nisse＠lysator.liu.se 05 Feb '15

05 Feb '15

Looking at http://www.lysator.liu.se/~nisse/nettle/plan.html, the most important things are done. I think documentation is the only item left which is both important and requires several hours of work. * Versioned symbols. I think this is complete, I just have forgotten to merge that branch. * Base64 with other alphabets. A patch was posted to the list some month ago, I had some comments, and then it seems to have stalled. If it's desirable to break the ABI to implement it, 3.1 may be the last chance for some years time. * OCB mode. Is it a good idea to try to get this into the release? I don't think patents are a problem, but I've mailed sflc, and it would be nice to get their opinion too. Needs not just the code, but also test cases and documentation. * Also OFB mode has been requested, used by openpgp, iirc. Anything else I've missed? And which of the above items are important? There are a lot of things that could be better optimized, including the curve25519 code and the aesni code, but I don't think the release should be delayed for that. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 10

OCB mode
by Nikos Mavrogiannopoulos 28 Jan '15

28 Jan '15

Hello, What do you think of having OCB mode in nettle? I particularly like OCB due to it's simplicity and performance comparing to GCM/CCM, but was always patented. However in [0] there is license1 which states: "Under this license, you are authorized to make, use, and distribute open-source software implementations of OCB. This license terminates for you if you sue someone over their open-source software implementation of OCB claiming that you have a patent covering their implementation." What do you think? Should the FSF be consulted on that? regards, Nikos [0]. http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

4 8

ecc.h vs ecc-internal.h
by nisse＠lysator.liu.se 27 Jan '15

27 Jan '15

I'm about to remove a lot of the internal declarations from ecc.h, and move the ones which still are needed to ecc-internal.h. Problem is that most of these functions work only with particular curve types, and are typically installed in function pointers in struct ecc_curve. If they really are needed as public functions, they must be reimplemented to jump via the appropriate function pointer. And some, like most or all of the corresponding itch functions, are not even defined anywhere anymore (replaced by macros in ecc-internal.h, and fields in struct ecc_curve). ecc_size_j is a borderline case, not sure if it should be public (if so, it should probably be renamed, and not mean "convert to jacobian coordinates", but "convert to whatever internal representation is appropriate for the curve". And everything below ecc_size_j in ecc.h should be removed. Any objections? Any function applications are relying on? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 2

Intel aes instructions
by nisse＠lysator.liu.se 25 Jan '15

25 Jan '15

I've just pushed new aes code using intel's aesni instructions. See https://git.lysator.liu.se/nettle/nettle/blob/530014f3f811d9018ec83a8748fdb… It gave a speedup of almost 10 times on the haswell machine where I tested it (and in addition, it should avoid sidechannel leaks in those functions). Clearly, this will be more useful after adding support for fat binaries, detecting presence of these instructions at runtime. For now, it has to be enabled explicitly with the configure argument --enable-x86-aesni. I have one question, on how to enable support for these instructions in the assembler. For now I added a pseudo-op .arch bdver2 and that seems to work, but it's a bit too specific for my taste. I would have preferred something like .arch generic64,aes, but I couldn't get that to work. So what's the right way to do this? I haven't played with the corresponding arch flags to gcc, but I'd prefer do declare within the .asm file itself which instruction set it is intended for. Feedback on the actual assembler code is also appreciated, of course. It's pretty basic, a dozen lines, no unrolling or other cleverness. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 34

Jump to page:

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