The removal of hashing from session generation worries me a little for two reasons:
1. The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. In the light of Snowden revelations and NSA backdoors, Jacob Appelbaum once proposed a drinking game where you read RFCs and every time you encounter a requirement of putting random bytes "on the wire", you drink.
Now the NSA might or might not have been able to backdoor all common PRNGs, but Dual EC DRBG was one good example. There's just no good reason not to use hashing before outputting raw bytes other than the reason they removed it from PHP: "less complexity" and improved performance. Then again, in PHP the method was quite complicated with too many tweak options.
2. What if no CSPRNG is available? They seem to fall back and just "read 60 bytes extra for faulty PRNGs", which to my knowledge does not help much in preventing predictability. With a bit of bad luck, this would make sessions entirely predictable.
I really wonder whether they couldn't have kept a single hashing algo in with good defaults, rather than allowing to tweak this stuff. That would have been a big speedup and complexity removal already.
You defend your invocation of one of Appelbaum's ideas before you actually invoke it. It's a bit cart-before-horse, and took me a couple of passes to parse, too. If you're that concerned about people taking the source as an impeachment of the idea, consider leaving out the former and describing only the latter; citing Appelbaum here adds only a perceived need to defend the concept, which should stand on merit alone if it has some.
1. The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. In the light of Snowden revelations and NSA backdoors, Jacob Appelbaum once proposed a drinking game where you read RFCs and every time you encounter a requirement of putting random bytes "on the wire", you drink.
Now the NSA might or might not have been able to backdoor all common PRNGs, but Dual EC DRBG was one good example. There's just no good reason not to use hashing before outputting raw bytes other than the reason they removed it from PHP: "less complexity" and improved performance. Then again, in PHP the method was quite complicated with too many tweak options.
2. What if no CSPRNG is available? They seem to fall back and just "read 60 bytes extra for faulty PRNGs", which to my knowledge does not help much in preventing predictability. With a bit of bad luck, this would make sessions entirely predictable.
I really wonder whether they couldn't have kept a single hashing algo in with good defaults, rather than allowing to tweak this stuff. That would have been a big speedup and complexity removal already.