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.
Martin Storsjö | 24 Jan 13:22 2015

[PATCH 1/2] arm: Add .arch directives for armv6

This allows building these files as part of a fat build, even if
the assembler by default targets a lower architecture version.
---
 arm/v6/aes-decrypt-internal.asm | 2 ++
 arm/v6/aes-encrypt-internal.asm | 2 ++
 arm/v6/sha1-compress.asm        | 1 +
 arm/v6/sha256-compress.asm      | 1 +
 4 files changed, 6 insertions(+)

diff --git a/arm/v6/aes-decrypt-internal.asm b/arm/v6/aes-decrypt-internal.asm
index 28d8f6f..3eab3eb 100644
--- a/arm/v6/aes-decrypt-internal.asm
+++ b/arm/v6/aes-decrypt-internal.asm
 <at>  <at>  -30,6 +30,8  <at>  <at>  ifelse(<
    not, see http://www.gnu.org/licenses/.
 >) 

+	.arch armv6
+
 include_src(<arm/aes.m4>)

 define(<PARAM_ROUNDS>, <r0>)
diff --git a/arm/v6/aes-encrypt-internal.asm b/arm/v6/aes-encrypt-internal.asm
index f7f4769..e4fa25d 100644
--- a/arm/v6/aes-encrypt-internal.asm
+++ b/arm/v6/aes-encrypt-internal.asm
 <at>  <at>  -30,6 +30,8  <at>  <at>  ifelse(<
    not, see http://www.gnu.org/licenses/.
 >) 

(Continue reading)

Niels Möller | 11 Jan 15:27 2015
Picon
Picon
Picon

Intel aes instructions

I've just pushed new aes code using intel's aesni instructions.
See

https://git.lysator.liu.se/nettle/nettle/blob/530014f3f811d9018ec83a8748fdbcd45e8ccc5d/x86_64/aesni/aes-encrypt-internal.asm

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

Nikos Mavrogiannopoulos | 16 Dec 13:02 2014

[Fwd: [gnutls-help] Generating DH Parameters larger than 3072 bits]

Hello,
 It seems that by switching gnutls to nettle 2.7.x for DSA (and DH) key
generation the forwarded issues occur. Would it be possible to have a
2.7.x release with the attached patch? That would allow gnutls 3.3.x
generate arbitrary DH parameters.

regards,
Nikos

_______________________________________________
nettle-bugs mailing list
nettle-bugs@...
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Eli Zaretskii | 12 Dec 17:02 2014
Picon

Potential bug in nettle-benchmark.c

This was flagged by GCC:

  nettle-benchmark.c: In function 'time_cipher':
  nettle-benchmark.c:504:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
	   memset(iv, 0, sizeof(iv));
			       ^
  nettle-benchmark.c:520:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
	   memset(iv, 0, sizeof(iv));
			       ^
  nettle-benchmark.c:537:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
	   memset(iv, 0, sizeof(iv));
			       ^

Here's a suggested patch:

--- examples/nettle-benchmark.c~0	2013-05-28 17:21:54.000000000 +0300
+++ examples/nettle-benchmark.c	2014-12-12 17:58:10.670625000 +0200
 <at>  <at>  -501,7 +501,7  <at>  <at>  time_cipher(const struct nettle_cipher *
 	info.block_size = cipher->block_size;
 	info.iv = iv;

-        memset(iv, 0, sizeof(iv));
+        memset(iv, 0, sizeof(*iv));

         cipher->set_encrypt_key(ctx, cipher->key_size, key);

 <at>  <at>  -517,7 +517,7  <at>  <at>  time_cipher(const struct nettle_cipher *
(Continue reading)

Amos Jeffries | 11 Dec 11:53 2014
Picon

Please add base-64 URL-safe alphabet


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.
diff --git a/base64-decode.c b/base64-decode.c
index f622baa..fbaf54f 100644
--- a/base64-decode.c
+++ b/base64-decode.c
 <at>  <at>  -43,7 +43,7  <at>  <at> 
(Continue reading)

Nikos Mavrogiannopoulos | 6 Dec 09:30 2014

function casts

It seems that in the GCM macros nettle uses casts to functions. That is
pretty dangerous with the changes of parameters in functions in nettle
3. The issue is the compiler will not warn for serious errors such as
different function type. An example macro is GCM_ENCRYPT.

#define GCM_ENCRYPT(ctx, encrypt, length, dst, src)                   \
  (0 ? (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0)             \
     : gcm_encrypt(&(ctx)->gcm, &(ctx)->key, &(ctx)->cipher,          \
                   (nettle_cipher_func *) (encrypt),                  \
                   (length), (dst), (src)))

I don't think that nettle should be casting functions. The issue seems
to be present in ctr, eax and cbc modes as well.

regards,
Nikos
Nikos Mavrogiannopoulos | 5 Dec 23:57 2014

patch: define API version number

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

_______________________________________________
nettle-bugs mailing list
nettle-bugs@...
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Nikos Mavrogiannopoulos | 24 Nov 15:14 2014
Picon

gcm + encrypt_message

I am trying to figure out how to wrap around CCM and GCM, and it seems
like a hard task. They are totally incompatible. Would it make sense
instead of have an equivalent of ccm_decrypt_message() in gcm as well,
and make that the AEAD API?

regards,
Nikos
Nikos Mavrogiannopoulos | 24 Nov 14:06 2014
Picon

symbol versioning

The attached patch will add symbol versioning in nettle. That would
mean that software linked against nettle 3.x will be able to
interoperate with libraries that are linked on a previous version of
nettle (and vice versa).

You could check the new symbol names with "readelf -Ws libnettle.so"

regards,
Nikos
_______________________________________________
nettle-bugs mailing list
nettle-bugs@...
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Nikos Mavrogiannopoulos | 23 Nov 22:58 2014

issues found while converting from 2.7 to 3.0

Hello,

* gcm.h:

The GCM_SET_KEY macro uses key both as input and to access a ctx
element, and thus requires the last parameter to be called "key" as
well.

#define GCM_SET_KEY(ctx, set_key, encrypt, key)                 \
  do {                                                          \
    (set_key)(&(ctx)->cipher, (key));                           \
    if (0) (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0);  \
    gcm_set_key(&(ctx)->key, &(ctx)->cipher,                    \
                (nettle_cipher_func *) (encrypt));              \
  } while (0)

* cbc.h:
cbc_encrypt and decrypt use const void* as first parameter. That is, it
cannot be wrapped over a function that works for cbc_encrypt as well as
gcm_aes_encrypt (the latter doesn't use const). Without casts that is.

Overall, what I didn't like it that the new cipher API required more
code to wrap around it.

* macros.h:
The MD_INCR(ctx) macro is now only applicable for sha512.

* nettle-types.h:
There is still nettle_crypt_func which is identical to
nettle_cipher_func. Is that intentional? I was wondering what was its
(Continue reading)


Gmane