Page MenuHomeFreeBSD

Fortuna: Clean up reseeding key material to closer match FS&K
ClosedPublic

Authored by cem on Aug 29 2018, 4:19 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 10, 11:24 PM
Unknown Object (File)
Mar 13 2024, 3:22 AM
Unknown Object (File)
Feb 4 2024, 10:08 PM
Unknown Object (File)
Feb 4 2024, 5:54 PM
Unknown Object (File)
Jan 25 2024, 4:24 PM
Unknown Object (File)
Jan 18 2024, 9:44 AM
Unknown Object (File)
Dec 20 2023, 3:22 AM
Unknown Object (File)
Dec 14 2023, 10:34 PM
Subscribers

Details

Summary

When reseeding, only incorporate actual key material. Do not include e.g.
the derived key schedules or other AES context.

I don't think the extra material was harmful here, just not beneficial.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/dev/random/fortuna.c
289 ↗(On Diff #47423)

The sentiment is good, but this looks a bit "magic number-ish". Dividing by 8 may give the right answer, but rather co-incidentially, no?

Would it not be more correct to have a specific sizeof(something)?

sys/dev/random/fortuna.c
289 ↗(On Diff #47423)

keyLen is stored in bits, but randomdev_hash_iterate() takes a number of bytes. sizeof(something) wouldn't be semantically correct, even if it produced the number 8 ;-).

See preexisting use of the 8 constant to translate between rijndael key lengths and ordinary byte lengths in e.g., dev/random/hash.c and crypto/rijndael/rijndael-api-fst.c.

(In general, FreeBSD MI code in general and crypto implementations in particular widely assume 8 bits per byte.)

markm added inline comments.
sys/dev/random/fortuna.c
289 ↗(On Diff #47423)

I geddit. keyless is in bits.

LGTM.

This revision is now accepted and ready to land.Aug 29 2018, 7:36 PM
delphij accepted this revision.
delphij added a reviewer: secteam.
This revision was automatically updated to reflect the committed changes.