Simon Josefsson <si...@josefsson.org> writes:
> Re the 3.0 plans, it seems that making a 3.0 release that implement the
> first two items on the list (unsigned->size_t, memxor namespace) would
> be possible to achieve relatively soon with modest investment in work.
I've done the memxor thing now, and I'm looking into size_t. When
switching to size_t, should we use it for *all* lengths, or only all
lengths which potentially are large? For an example, consider aes.h:
I think it's clear that we ought to switch to size_t for
void
aes_encrypt(const struct aes_ctx *ctx,
unsigned length, uint8_t *dst,
const uint8_t *src);
void
aes_decrypt(const struct aes_ctx *ctx,
unsigned length, uint8_t *dst,
const uint8_t *src);
(not that it seems particularly likely that those functions will be
called with more than 4GB at a time, but the API shouldn't make it
impossible). But what about
void
aes_set_encrypt_key(struct aes_ctx *ctx,
unsigned length, const uint8_t *key);
The length here must be one of the integers 16, 24 or 32. Should we stick
to unsigned here, or use size_t for consistency?
Other key sizes are a bit more subtle. E.g., hmac keys can be up to 2^64
bits (or whatever is the maximum size of the underlying hash function,
like the ridiculously large limit of 2^128 bits for SHA512), but all
keys used in practice are going to have a size which fit in 32 bits (or
even 16 bits. RSA bitsizes are similarly unlimited in theory but pretty
small in any reasonable practice.
I think it would make some sense to adopt the principle that key sizes
use unsigned (since keys by definition are small objects), and message
sizes use size_t. Which would still leave some corner cases, like
rsa_encrypt where only messages of small size (depending on the key
size) are possible.
Comments?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
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
