Simon Josefsson writes:
> This adds DRBG-CTR-AES256, what do you think?
Thanks, I've had a first look.
> --- /dev/null
> +++ b/drbg-ctr-aes256.c
> @@ -0,0 +1,100 @@
> +/* drbg-ctr-aes256.c
> +static void
> +drbg_ctr_aes256_update (struct aes256_ctx *Key,
> + uint8_t *V, uint8_t *provided_data)
> +{
> + uint8_t tmp[DRBG_CTR_AES256_SEED_SIZE];
> +
> + INCREMENT (AES_BLOCK_SIZE, V);
> + aes256_encrypt (Key, AES_BLOCK_SIZE, tmp, V);
> +
> + INCREMENT (AES_BLOCK_SIZE, V);
> + aes256_encrypt (Key, AES_BLOCK_SIZE, tmp + AES_BLOCK_SIZE, V);
> +
> + INCREMENT (AES_BLOCK_SIZE, V);
> + aes256_encrypt (Key, AES_BLOCK_SIZE, tmp + 2 * AES_BLOCK_SIZE, V);
You could perhaps use ctr_fill16 or something similar for this,
currently a static function in ctr.c. Even though I guess it's
appropriate to aim for clarity rather than highest performance for this
function.
Hmm, or fill tmp with zeros, followed by a call to _nettle_ctr_crypt16
(implies a redundant memxor operation, but perhaps simpler code)?
> +void
> +drbg_ctr_aes256_random (struct drbg_ctr_aes256_ctx *ctx,
> + size_t n, uint8_t *dst)
> +{
> + while (n >= AES_BLOCK_SIZE)
> +{
> + INCREMENT (AES_BLOCK_SIZE, ctx->V);
> + aes256_encrypt (&ctx->Key, AES_BLOCK_SIZE, dst, ctx->V);
> + dst += AES_BLOCK_SIZE;
> + n -= AES_BLOCK_SIZE;
> +}
Here too, could gain performance by filling the output buffer with ctr
values and do a single call to aes256_encrypt.
> +struct drbg_ctr_aes256_ctx
> +{
> + struct aes256_ctx Key;
> + uint8_t V[AES_BLOCK_SIZE];
> +};
It's closer to Nettle style with lower case names, at least for "key".
And V could use the type union nettle_block16 (which provides stricter
alignment than a uint_8).
> +@subsection DRBG-CTR
> +
> +The Deterministic Random Bit Generator (DRBG) family is a complex family
> +of deterministic randomness generators published by NIST in SP 800-90A.
It would be good with a reference to the spec also in the .c or .h file.
> +We support what we believe is the reasonable parts of the CTR_DRBG
> +algorithm for AES256. Re-seeding, personalization strings, derivation
> +functions and support for non-AES256 is not implemented.
> +Personalization strings can be implemented by the caller, if desired,
> +with xor. If you need re-seeding or entropy derivation, we suggest that
> +you use Yarrow instead.
Side question: Is Yarrow still a reasonable recommendation, or would it
be good to add some alternative (either its successor Fortuna, or
something completely different)?
> +Our suggested use-case for DRBG-CTR is to deterministically generate
> +known values from a seed when comparing against expected values for some
> +other algorithm.
That's a rather limited usecase. Do you think it's inappropriate to use,
e.g., to expand a short secret seed into multiple subkeys?
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se
To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
