In the context of >> What's your threat model?
>> Are you designing to resist an output-text-only attack? Or do you also want >> "some" ability to recover from a compromise of the PRNG internal state? On 06/26/2017 11:51 AM, Salz, Rich wrote: > Our TCB border is the process. That doesn't answer the question. > then something like chacha. That doesn't answer the question either. ============ I'm not mentioning any names, but some people are *unduly* worried about recovery following compromise of the PRNG internal state, so they constantly re-seed the PRNG, to the point where it becomes a denial-of-service attack against the upstream source of randomness. This is also mostly pointless, because any attack that compromises the PRNG state will likely compromise so many other things that recovery will be very difficult. All future outputs will be suspect. So please let's not go overboard in that direction. On the other hand, it seems reasonable to insist on /forward/ secrecy. That is, we should insist that /previous/ outputs should not be compromised. This is achievable at small but not-quite-zero cost. Specifically, ChaCha (or any other cipher) in counter mode does *not* provide forward secrecy when the PRNG state is compromised. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev