Simon Josefsson simon@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