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.
Details
Details
- Reviewers
delphij markm jmg - Group Reviewers
secteam O3: Kernel Random Numbers Generator (Owns No Changed Paths) - Commits
- rGec2942baf536: Fortuna: Clean up reseeding key material to closer match FS&K
rS339479: Fortuna: Clean up reseeding key material to closer match FS&K
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 19255 Build 18868: arc lint + arc unit
Event Timeline
| sys/dev/random/fortuna.c | ||
|---|---|---|
| 289 | 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 | 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.) | |
| sys/dev/random/fortuna.c | ||
|---|---|---|
| 289 | I geddit. keyless is in bits. LGTM. | |