Thank you for your review. Before I send you an updated patch I have a few
questions.
> + r %= mod;
>Division is a pretty expensive operation. If this loop is in any way
>performance critical, there are ways to speed up this arithmetic.
How would you recommend speeding it up?
> + }
> + return r;
> +}
> +
> +void
> +balloon(size_t passwd_len, const uint8_t *passwd,
> + size_t salt_len, const uint8_t *salt,
> + unsigned s_cost, unsigned t_cost,
> + const struct nettle_hash *alg,
> + uint8_t *buf, uint8_t *result)
> +{
>For consistency, can you see if you can make the interface/function
>signature closer to the pbkdf2 function (see pbkdf2.h)? It takes a
>pointer to a mac context, already initialized by the caller (in this
>case, it would instead be a hash context), function pointers for update
>and digest, and the digest size.
The closest function signature I can think of would look like this:
void
balloon(void *hash_ctx,
nettle_hash_update_func *update,
nettle_hash_digest_func *digest,
size_t digest_size, uint *buf,
size_t s_cost, size_t t_cost,
size_t passwd_length, const uint8_t *passwd,
size_t salt_length, const uint8_t *salt,
size_t length, uint8_t *dst)
But isn't 13 argument function an overkill?
Would this function signature be ok or would you recommend something else?
>What are reasonable values for the s_cost and t_cost? Will an unsigned
>(usually 32 bits, but might be as small as 16 on some compilers for
>embedded systems) always be large enough? Alternatives include uint32_t,
>uint64_t (likely much overkill? But in principle, I guess one could run
>ballon with a buffer size of a few dozen GB?) and size_t.
Good point. I think it might be reasonable for someone to want a buffer
size of a few GB in extreme cases.
I can put s_cost and t_cost as size_t. I think there is no harm in doing
that. Is that ok if I put them as size_t?
Kind regards,
Zoltan
_______________________________________________
nettle-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
