Niels Möller | 24 Apr 22:21 2015
Picon
Picon
Picon

ANNOUNCE: Nettle-3.1.1

I've made another release of GNU Nettle, a low-level
cryptographics library, to fix bugs reported for Nettle 3.1.

The Nettle home page can be found at
http://www.lysator.liu.se/~nisse/nettle/, and the manual at
http://www.lysator.liu.se/~nisse/nettle/nettle.html.

NEWS for the Nettle 3.1.1 release

	This release fixes a couple of non-critical bugs.

	Bug fixes:

	* By accident, nettle-3.1 disabled the assembly code for the
	  secp_224r1 and secp_521r1 elliptic curves on all x86_64
	  configurations, making signature operations on those curves
	  10%-30% slower. This code is now re-enabled.

	* The x86_64 assembly implementation of gcm hashing has been
          fixed to work with the Sun/Oracle assembler.

	The shared library names are libnettle.so.6.1 and
	libhogweed.so.4.1, with sonames still libnettle.so.6 and
	libhogweed.so.4. It is intended to be fully binary compatible
	with nettle-3.1.

Available at:

  https://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gz
  ftp://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gz
(Continue reading)

Niels Möller | 22 Apr 19:00 2015
Picon
Picon
Picon

Re: bug against .short value

dongsheng zhang <dongsheng.zhang@...> writes:

> Solaris doesn't take .short value, but instead only takes .value value.
> We thus cannot compile the following file:
> nettle-3.1/x86_64/gcm-hash8.asm

I've checked in a fix. Can you try to check out

  https://git.lysator.liu.se/nettle/nettle.git

and test if it solves the problem? You need to run the script
./.boostrap before configure and make.

Regards,
/Niels

--

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Niels Möller | 21 Apr 19:30 2015
Picon
Picon
Picon

Re: bug against .short value

dongsheng zhang <dongsheng.zhang@...> writes:

> Solaris doesn't take .short value, but instead only takes .value value.
> We thus cannot compile the following file:
> nettle-3.1/x86_64/gcm-hash8.asm

I see. From some testing, it seems that GNU as treats all of .short,
.word, .value and .2byte as aliases, defining 16-bit constants.

We currently use .short, and that breaks x86_64 builds using the
Sun/Oracle assembler. Does anyone know which of ".word", ".value" and
".2byte" is more portable (.value sounds very unspecific to me)? I'd
prefer to use a pseudo op supported by all relevant x86_64 assemblers,
and not have to add a configure test for this.

I think the relevant assemblers are GNU as (including older versions),
Sun/Oracle as, and the assembler used with clang on freebsd.

Regards,
/Niels

--

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Niels Möller | 26 Mar 22:37 2015
Picon
Picon
Picon

nettle-3.1rc1

Available now, at

  http://www.lysator.liu.se/~nisse/archive/nettle-3.1rc1.tar.gz
  http://www.lysator.liu.se/~nisse/archive/nettle-3.1rc1.tar.gz.sig

There's also a corresponding tag in the repo (except that the suffix
"rc1" on the package version in configure.ac is not committed).

All testing and proof-reading highly appreciated.

Regards,
/Niels

--

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Niels Möller | 25 Mar 23:44 2015
Picon
Picon
Picon

Getting closer to nettle-3.1

I think the remaining items on
http://www.lysator.liu.se/~nisse/nettle/plan.html aren't very urgent,
and can be postponed.

Discussed recently, but not on that list, is mem_equalp (or whatever it
should be called). That's also not very urgent.

I plan to move NETTLE_USE_MINI_GMP from bignum.h to version.h, and drop
bignum.h.in. It should be enough with one configure-generated header
like that. It also has the advantage that version.h actually gets used
during the build. That change touches a couple of files, so I don't want
to check that in tonight.

Anyway, I think it's time to get into final testing. I've done some
tests on freebsd, revealing one real bug (triggered only when compiled
with the ancient gcc version freebsd keeps in /usr/bin). And I've made
some fixes to what gets included by make dist.

I hope to be able to create a nettle-3.1rc1.tar.gz in a day or two.

Regards,
/Niels

--

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Nikos Mavrogiannopoulos | 19 Mar 11:01 2015
Picon

patch: added missing dist files


_______________________________________________
nettle-bugs mailing list
nettle-bugs@...
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Martin Sebor | 16 Mar 21:33 2015
Picon

test failures on powerpc64le-redhat-linux


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:
(Continue reading)

Niels Möller | 14 Mar 08:20 2015
Picon
Picon
Picon

memeql_sec

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
(Continue reading)

Niels Möller | 26 Feb 11:03 2015
Picon
Picon
Picon

curve25519 and eddsa

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

(Continue reading)

Niels Möller | 28 Jan 21:35 2015
Picon
Picon
Picon

nettle-3.1 loose ends

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.
(Continue reading)

Niels Möller | 26 Jan 09:35 2015
Picon
Picon
Picon

ecc.h vs ecc-internal.h

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.

Gmane