Nikos Mavrogiannopoulos <[email protected]> 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
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
