Niels Möller <[email protected]> writes: > Simon Josefsson <[email protected]> writes: > >> This adds DRBG-CTR-AES256, what do you think? > > Thanks, I've had a first look.
Thanks for review! >> + 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)? I started looking at ctr* too, but ended up doing more and more changes to ctr*c than I felt comfortable with since I don't understand those functions well enough. One issue is that DRBG-CTR increments before AES, and normal CTR has the reverse order. >> +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)? Fortuna is newer but I wonder if anyone will ever use Nettle to implement this functionality? Maybe the Nettle documentation could suggest that anyone considering Yarrow should research alternatives first. >> +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? I would use HKDF for that. DRBG-CTR is strange in several ways (e.g., non-uniform seeds), to the point of being unsafe since it is easy to misuse it. Considering Dual-EC-DRBG, perhaps standardizing "problematic" prng's was a design goal with 800-90A, and in that case the DRBG-CTR designs makes a whole lot more sense and would be an appropriate algorithm. Maybe it should only be added as internal functionality to Nettle... /Simon
signature.asc
Description: PGP signature
_______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
