I have updated the release plans, at
http://www.lysator.liu.se/~nisse/nettle/plan.html. I aim to get a
release out within a month or two.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
The machine git.lysator.liu.se is being upgraded to a more recent debian
version. Not sure when it will be operational again (it's maintained on
a volunteer basis), but hopefully within a day or two.
Possibly the gitorious web interface will be replaced by something
different (gitolite, gitlab, ...), since gitorious seems to require quite
a bit of work to install.
Sorry for the inconvenience.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email …
[View More]is subject to wholesale government surveillance.
[View Less]
I'm happy to annnounce a new version of GNU Nettle, a low-level
cryptographics library. The Nettle home page can be found at
http://www.lysator.liu.se/~nisse/nettle/.
One serious bug has been found in the new ECC code shipped in
nettle-2.7. Thanks to Magnus Holmgren for help tracking down this
problem.
NEWS for the 2.7.1 release
This is a bugfix release.
Bug fixes:
* Fixed a bug in the new ECC code. The ecc_j_to_a function
called GMP:s mpn_mul_n (via ecc_modp_mul) with overlapping
…
[View More]input and output arguments, which is not supported.
* The assembly files for SHA1, SHA256 and AES depend on ARMv6
instructions, breaking nettle-2.7 for pre-v6 ARM processors.
The configure script now enables those assembly files only
when building for ARMv6 or later.
* Use a more portable C expression for rotations. The
previous version used the following "standard" expression
for 32-bit rotation:
(x << n) | (x >> (32 - n))
But this gives undefined behavior (according to the C
specification) for n = 0. The rotate expression is replaced
by the more portable:
(x << n) | (x >> ((-n)&31))
This change affects only CAST128, which uses non-constant
rotation counts. Unfortunately, the new expression is poorly
optimized by released versions of gcc, making CAST128 a bit
slower. This is being fixed by the gcc hackers, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157.
The following problems have been reported, but are *not* fixed
in this release:
* ARM assembly files use instruction syntax which is not
supported by all assemblers. Workaround: Use a current
version of GNU as, or configure with --disable-assembler.
* Configuring with --disable-static doesn't work on windows.
The libraries are intended to be binary compatible with
nettle-2.2 and later. The shared library names are
libnettle.so.4.7 and libhogweed.so.2.5, with sonames still
libnettle.so.4 and libhogweed.so.2.
Available at
http://ftp.gnu.org/gnu/nettle/nettle-2.7.1.tar.gzftp://ftp.gnu.org/gnu/nettle/nettle-2.7.1.tar.gzhttp://www.lysator.liu.se/~nisse/archive/nettle-2.7.1.tar.gz
and in the "nettle-2.7-fixes" branch in the git repository, see
http://git.lysator.liu.se/nettle/nettle.
Happy hacking,
/Niels Möller
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]
Hello,
Trying to build nettle 2.7 for an arm10 system of mine using its (old)
toolchain fails with assembler errors.
arm-linux-gcc -Os -I[...] -I. -DHAVE_CONFIG_H -g -O2 -ggdb3
-Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith -Wbad-function-cast
-Wnested-externs -fpic -MT aes-decrypt-internal.o -MD -MP -MF
aes-decrypt-internal.o.d -fpic -c aes-decrypt-internal.s
aes-decrypt-internal.s: Assembler messages:
aes-decrypt-internal.s:…
[View More]81: Error: bad instruction `push
{r4,r5,r6,r7,r8,r10,r11,lr}'
aes-decrypt-internal.s:87: Error: register or shift expression expected
-- `orr r4,r8,lsl#8'
aes-decrypt-internal.s:89: Error: register or shift expression expected
-- `orr r4,r8,lsl#16'
aes-decrypt-internal.s:91: Error: register or shift expression expected
-- `orr r4,r8,lsl#24'
aes-decrypt-internal.s:93: Error: bad arguments to instruction -- `eor
r4,r8'
[...]
make[2]: *** [aes-decrypt-internal.o] Error 1
$ arm-linux-as -v
GNU assembler version 2.16.1 (arm-linux-uclibc) using BFD version 2.16.1
Trying with the latest buildroot another error is issued:
arm-buildroot-linux-uclibcgnueabi-as -v
GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using
BFD version (GNU Binutils) 2.21.1
arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os
-Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith -Wbad-function-cast
-Wnested-externs -fpic -MT aes-encrypt-internal.o -MD -MP -MF
aes-encrypt-internal.o.d -fpic -c aes-encrypt-internal.s
aes-encrypt-internal.s: Assembler messages:
aes-encrypt-internal.s:140: Error: selected processor does not support
ARM mode `uxtb r8,r2'
aes-encrypt-internal.s:142: Error: selected processor does not support
ARM mode `uxtb r8,r3'
aes-encrypt-internal.s:144: Error: selected processor does not support
ARM mode `uxtb r8,r12'
aes-encrypt-internal.s:146: Error: selected processor does not support
ARM mode `uxtb r8,r14'
Any ideas?
regards,
Nikos
[View Less]
Testing on the debian build machines revealed a bug in the new ecc code.
Curiously enough, causing failures only on 32-bit sparc (see
https://buildd.debian.org/status/fetch.php?pkg=nettle&arch=sparc&ver=2.7-2&…),
but the bug is not really platform-specific.
It turned out that ecc_j_to_a called GMP:s mpn_mul_n (via ecc_modp_mul)
with overlapping input and output arguments, which is not supported.
The following patch seems to solve the problem:
diff --git a/ecc-j-to-a.c b/ecc-j-to-…
[View More]a.c
index df8b876..26c1a03 100644
--- a/ecc-j-to-a.c
+++ b/ecc-j-to-a.c
@@ -46,6 +46,7 @@ ecc_j_to_a (const struct ecc_curve *ecc,
#define up (scratch + ecc->size)
#define iz2p (scratch + ecc->size)
#define iz3p (scratch + 2*ecc->size)
+#define izBp (scratch + 3*ecc->size)
#define tp scratch
mp_limb_t cy;
@@ -72,11 +73,11 @@ ecc_j_to_a (const struct ecc_curve *ecc,
if (flags & 1)
{
/* Divide this common factor by B */
- mpn_copyi (iz3p, izp, ecc->size);
- mpn_zero (iz3p + ecc->size, ecc->size);
- ecc->redc (ecc, iz3p);
-
- ecc_modp_mul (ecc, iz2p, izp, iz3p);
+ mpn_copyi (izBp, izp, ecc->size);
+ mpn_zero (izBp + ecc->size, ecc->size);
+ ecc->redc (ecc, izBp);
+
+ ecc_modp_mul (ecc, iz2p, izp, izBp);
}
else
ecc_modp_sqr (ecc, iz2p, izp);
Thanks to Magnus Holmgren for tracking this down.
Note that this bug causes overwrites *within* a properly allocated limb
array, which gives incorrect results, but it does not overwrite any
pointers or code.
I should plan for a bugfix release reasonably soon.
Testing with a GMP library compiled with --enable-assert would have
revealed the bug earlier.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]
I'm rewriting the cast128 key schedule, to get rid of false warnings, and
avoid lots of conditions, and to separate the rotation and the mask
subkeys.
Then I noticed a portability problem with the rotation macros,
#define ROTL32(n,x) (((x)<<(n)) | ((x)>>(32-(n))))
For n == 0, this will work on most machines, but it's not portable,
since x >> 32 gives undefined behaviour according to the C spec (when x
is a 32-bit type). (On typical hardware, the result of x >> 32 …
[View More]will be
either x or 0, and the rotation macro gives the intended result in
either case).
In most of nettle, there's no problem, because rotation counts are
constant and non-zero.
cast128 is an exception, with key-dependent rotation counts, which can
well be zero (don't know if that's exercised by the test suite, though).
A fix is to redefine the macro as
#define ROTL32(n,x) (((x)<<(n)) | ((x)>>((-(n))&31)))
It should make no difference when n is constant, but for cast128, this
portability fix makes the code almost 20% slower. Apparently, gcc,
doens't recognize this as a rotate. I just filed a bug report at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157
Is there any other trick I'm missing, which is portable C but which
doesn't slow it down when compiled with gcc?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
[View Less]