I fully agree with you on that one time pads need more a computationally secure algorithm with an initial seed. This is why I found tptacek comment a bit strange. One time pads generators are cryptographic applications.
> lack forward secrecy
>> I don't understand how people who understand the relationship between CSPRNGs and (say) CTR mode can believe that there's merit to using /dev/random after urandom has been seeded.
I would say that forward security is a good counter to the argument that urandom only, ever, need a initial seed. urandom need to be constantly updated with more entropy to maintain forward security.
This mean that after reboot, any cryptographic application that use urandom will run the risk of loosing forward secrecy if the saved seed is someone recovered (say, from backup).
That makes me also wonder, are the stored seed securely erased on Linux after boot?
Well, I guess "there is absolutely no security benefit to using /dev/random, for any cryptographic application" is a slight overgeneralization, because a one time pad is, as you say, a cryptographic application. But not much of one because the vast majority of the time you are not generating a one time pad.
As for forward secrecy, as I understand it, /dev/urandom is constantly updated with more entropy to maintain forward secrecy. In fact it is updated in exactly the same way as /dev/random. The only difference between /dev/urandom and /dev/random is that /dev/random blocks when it deems you have "run out of entropy" (which is really nonsense).
So even if the saved seed is compromised, as soon as enough new entropy comes in, /dev/urandom will be secure again. Also note that if the seed is compromised, /dev/random is not much better because it doesn't know that the seed has been compromised. So /dev/random will freely produce for you up to N bits of tainted output based on the broken seed, where N is the current entropy estimate.
This stored seed sound more and more as a very dangerous concept, and /dev/urandom should really just block until enough entropy has been gathered like in FreeBSD. That /dev/random would ever use the stored seed is very worrisome. Thanks for that piece of insight.
> I fully agree with you on that one time pads need more a computationally secure algorithm with an initial seed.
No. One-time pads require true randomness. Any algorithm involving a pseudorandom-generator, no matter how computationally secure, is actually simply a stream cipher.
