dbarysh...@gmail.com writes:
> It makes little sense to have intermediate solution with GCM_TABLE_BITS
> == 4. One either will use unoptimized case of GCM_TABLE_BITS == 0, or
> will switch to fully optimized case (8) as memory usage difference is
> quite low between 4 and 8. So drop GCM_TABLE_BITS == 4 support
For the const shift_table, the size difference is 32 bytes vs 512 bytes,
which may not be a big deal.
I'm more concerned with the size of struct gcm_key, 256 bytes vs 4096
bytes. GCM_TABLE_BITS == 4 seems like a reasonable tradeoff if you have an
embedded system with little RAM.
It's unfortunate that it is poorly tested. It would make some sense with
an (abi-breaking) configure flag --enable-small-size to reduce size of
various tables, which could then be tested more regularly. Besides gcm,
AES and DES use large constant tables of somewhat configurable size, and
for ecc there are both constant tables, for ecc_mul_g, and run-time
tables for ecc_mul_a.
Is there any interest in improving support for low-end embedded devices?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
