Nikos Mavrogiannopoulos nmav@gnutls.org writes:

Thanks. I've added the chacha ciphersuites into gnutls, and run the TLS benchmarks (with AES acceleration disabled): RSA_AES_128_GCM_SHA256 84.49 MB/sec RSA_AES_128_CCM 65.35 MB/sec RSA_CHACHA20_POLY1305 200.33 MB/sec

When AESNI/PCLMUL are enabled: RSA_AES_128_GCM_SHA256 1.19 GB/sec RSA_AES_128_CCM 0.27 GB/sec RSA_CHACHA20_POLY1305 0.20 GB/sec

I guess chacha will be good for smaller systems which have no hw AES acceleration.

Or if you suspect that your communication partners will advertise aes support, but have no hw aes.

Also, note that GCM has a pretty large per session memory footprint, so if you have lots of simultaneous sessions, I'd expect cache misses could reduce performance quite a lot compared what you'd expect from the benchmark numbers.

One small comment. I liked the ccm_encrypt_message() in ccm.h and would be nice if it would be come the default interface provided by all AEAD ciphers in nettle.

I think we should add something like

void aead_encrypt_message(const stuct nettle_aead *, void *ctx, size_t nlength, const uint8_t *nonce, size_t alength, const uint8_t *adata, size_t clength, uint8_t *dst, const uint8_t *src);

int aead_decrypt_message(const stuct nettle_aead *, void *ctx, size_t nlength, const uint8_t *nonce, size_t alength, const uint8_t *adata, size_t mlength, uint8_t *dst, const uint8_t *src);

And there could be wrapper functions/macros for particular aead algorithms as well, so the user doesn't have to care about the struct nettle_aead.

Patches welcome. But that will be for a later release.

Regards, /Niels

On Mon, Mar 30, 2015 at 9:56 PM, Niels Möller nisse@lysator.liu.se wrote:

nisse@lysator.liu.se (Niels Möller) writes:

...

All testing and proof-reading highly appreciated.

I've now done some more testing on x86_64 freebsd and arm gnu/linux (in addition to my main development platform, gnu/linux x86_64, and fixed a couple of mostly configure-related bugs. Then I tried windows cross compilation using mingw. w64 seems to fail several tests (at least according to wine). Likely ABI issues in some of the assembly files. Good news is that it seems 64-bit wine works out of the box with debian jessie.

Something that I just noticed is that chacha_poly1305_encrypt() returns a void value. However this function is limited to 2^32 data which is not really an expected upper bound. Shouldn't the encrypt function return an int instead and notify callers of overflow?

regards, Nikos

On Tue, Mar 31, 2015 at 9:22 AM, Niels Möller nisse@lysator.liu.se wrote:

...

Something that I just noticed is that chacha_poly1305_encrypt() returns a void value. However this function is limited to 2^32 data which is not really an expected upper bound.

At least the limit ought to be documented, and maybe backed up by an assert. I hesitate to add a return value for this. Where do you see a 2^32 limit? If I remember this correctly, it uses chacha with 96 bit nonce and 32 bit counter, where counter 0 is used for key setup. So this limits the message size to (2^32-1)*64, appr. 250 GB. If there is any smaller limit, that's likely a bug.

Indeed I meant 2^32 operations. My current hard drives are larger than 250 GB so I guess that is not a terrible limit. For gnutls it doesn't matter much as we encrypt per packet which are small, but if any applications use nettle to encrypt large files will trigger that. An assert() while is better than nothing it means a crash in the application that will attempt to encrypt that data, and I'm not sure that applications should be responsible for counting the data they input to individual ciphers. The limits change per cipher, and nettle already has a counter.

regards, Nikos

nisse@lysator.liu.se (Niels Möller) writes:

I've made an rc2 tarball, fixing known issues, except for the w64 problems which I haven't had time to debug yet.

I think I have found the w64 problem. It breaks with mini-gmp.

The problem is, x86_64 assembly files like, e.g, x86_64/ecc-244-modp.asm assumes that GMP_NUMB_BITS == 64. And when building with mini-gmp, mp_limb_t is unsigned long, and with the microsoft w64 ABI, that's a 32-bit type, so we get GMP_NUMB_BITS == 32.

I think the correct way is to add some markup to the assembly files saying what value of GMP_NUMB_BITS they need, and exclude files which expect a value different from the one detected by configure.

Regards, /Niels

nisse@lysator.liu.se (Niels Möller) writes:

I've made an rc3 tarball.

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

I haven't seen much feedback. Please test, and report failures as well as successes. I'm not aware of any issues in rc3. I have done some successful testing on

x86_64 GNU/Linux (64- and 32-bit),

x86_64 FreeBSD (64-bit only, since support for 32-bit toolchain tends to be broken)

ARM GNU/Linux (32-bit only)

Sparc Solaris (64-bit and 32-bit, compiling with gcc)

x86_64 MS Windows (64-bit and 32-bit, using mingw and wine)

So missing testing includes MacOS tests, tests on any real MS Windows systems, and any testing with non-gcc compilers.

I will be partly offline over the Easter weekend, and also away from my release signing keys. I will therefore cut the release on Tuesday April 7, most likely in the evening (European time).

Regards, /Niels

Amos Jeffries squid3@treenet.co.nz writes:

If this mp_limb_t type being long is a generic thing it is likely affecting other 32-bit OS with mini-gmp in the same way.

I don't think it's a very general problem. First, that assembly code expects a particular size of mp_limb_t affects only the few architectures for which Nettle includes any assembly code. Second, the problem was a 64-bit platform using a 32-bit unsigned long. As far as I'm aware, 64-bit windows is fairly unique in this choice of ABI (and there have been a couple of other workarounds related to that).

Anyway, the current mechanism, marking assembly files with the expected GMP_NUMB_BITS, can be added to other assembly files if the need arises.

Regards, /Niels