Not sure how I missed it, but yeah, least I read the thread. -Prashant
On 16 December 2016 at 08:13:13, [email protected] ([email protected]) wrote: > Send dsfjdssdfsd mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dsfjdssdfsd digest..." > Today's Topics: > > 1. Any readers here? Re: Risks of entropy available (Dan Brown) > 2. Re: Any readers here? Re: Risks of entropy available > (Paul Hoffman) > Is anybody still reading this list? > > Not sure if my previous post below was clear enough, but if it was clear and > if it was read, > then maybe it's just not concerning enough to justify a reply? > > Sent from my BlackBerry 10 smartphone on the Rogers network. > From: Dan Brown > Sent: Monday, November 28, 2016 11:51 AM > To: [email protected] > Subject: [dsfjdssdfsd] Risks of entropy available > > > Some RNGs (including some versions of Linux /dev/random) have an interface > that exposes > the estimated amount of entropy in the secret state of the RNG. > > If an adversary gains access to this interface, then there is a small risk > that sensitive > information leaks to the adversary, because the entropy estimate may be > derived from > and correlated to sensitive information. > > Just to be clear, I do not see this to be a serious risk. It would be > difficult to exploit. > Yet I do not see enough benefit in this interface to support taking this risk. > > This issue has probably been discussed elsewhere, maybe with different > conclusions > from, and better reasoning than, mine. If so, then a reply could just point > to those discussions. > > --- > > More detail sketched out below: > > The entropy in the RNG must necessarily be derived from secret sources. In > many systems, > the secret sources include things like keyboard input timings, which can be > further > classified as sensitive sources. The estimated entropy is also derived in > some way from > these secret sensitive sources. This derivation of the estimated entropy is > not generally > a cryptographically strong one-way function. Furthermore, the timing > information > might be leaked even if estimation is somehow one-way. Therefore, the > interfaces leaks > information about the sensitive sources. > > For a concrete example, the interface might leak information about the > keyboard timings, > which might in turn leak information about the values of the key inputs (if, > say, there > is a correlation between the values and timings, which might be the case, if > say the difference > key-down and key-up times vary significantly between different keyboard > inputs). > > I don’t see much value of providing this estimated-entropy interface at all. > Arguably, > system administrators might find it useful to know whether the system is in a > secure state > (perhaps to diagnose some kind of problem). Obviously, this interface does > not escalate > a system administrator’s already high privileges. But providing this > interface to > non-privileged processes risks exposure of sensitive information to > unauthorized > processes. > > A simple way to reduce this risk would be to deny access to non-privileged > users, disallowing > them to see the run-time entropy estimate. > > A more severe recommendation (Barak and Halevi, http://ia.cr/2005/029) is to > not keep > a run-time estimate of entropy. > > But some security goals do need live entropy, which might suggest using some > limited > run-time entropy estimation. For example, NIST SP 800-90* standards have a > notion of > prediction resistance (which is similar of Linux /dev/random’s blocking > interface). > In this mode, the RNG waits until it deems it has enough, presumably fresh > entropy. The > ostensible purpose is to recover from past temporary state-exposures. The > NIST approach > is gather to fresh entropy from a live noise source. If this noise source has > its entropy > assessed only at design time, not at run-time, then Barak and Halevi’s > recommendation > (of no run-time entropy estimation), can be followed. The NIST standards > might, however, > have some mild health test checks of entropy source, which only aim to detect > severe failure, > making them only mildly incompatible with the Barak-Halevi approach. > > If I understand correctly, the recent /dev/random approaches are to decrease > the estimate > entropy on an ongoing basis (such as during calls /dev/random), to ensure the > current > pool is deemed to be fresh entropy. The freshness so obtained might have a > purpose similar > to NIST’s security goal of prediction resistance (recovery from temporary > state-compromise). > Unfortunately, this step of decreasing the entropy estimate increases the > risk of the > interface. For example, if the entropy is in a near full state, then > /dev/random might > cease to increase its entropy estimate. In this full state, the leak is > reduced or stopped, > because the entropy estimate does not change as often. To circumvent this > obstacle, > the adversary can draw down the entropy estimate by calling /dev/random, > thereby cause > the RNG to decrease its entropy estimate. In so doing, the adversary can > change the RNG > state from non-leaky back to leaky. (The issue of calls to /dev/random being > abused for > another purpose to cause a denial of service has already been largely > mitigated by changes > in the /dev/random system.) > > The entropy estimate interface exposes more information than the blocking > behavior > of something like /dev/random, in that the entropy estimate numbers contain > more information > than the single bit of blocked/non-blocked state, and further the entropy > estimate > changes more frequently than the blocking state. But even the blocking > behavior of /dev/random > has the potential to leak a miniscule information, such as the timing > information. For > example, a malicious non-privileged process might call /dev/random very > frequently > until it blocks. Whether another user, say the system administrator, on the > system types > sensitive keyboard input into another process, /dev/random may unblock. The > malicious > process can then gather some timing information about the keyboard inputs. I > see this > as a much smaller risk, which is arguably worth the benefit of the prediction > resistance > properties of /dev/random. Again, the reason it is smaller risk is that > blocking state > changes much less frequently than the entropy estimate. Monitoring changes in > the entropy > estimate can therefore much more precise timing information. > > Best regards, > > Dan Brown > > [BlackBerry] > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, > privileged material (including material protected by the solicitor-client or > other > applicable privileges), or constitute non-public information. Any use of this > information > by anyone other than the intended recipient is prohibited. If you have > received this > transmission in error, please immediately reply to the sender and delete this > information > from your system. Use, dissemination, distribution, or reproduction of this > transmission > by unintended recipients is not authorized and may be unlawful. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, > privileged material (including material protected by the solicitor-client or > other > applicable privileges), or constitute non-public information. Any use of this > information > by anyone other than the intended recipient is prohibited. If you have > received this > transmission in error, please immediately reply to the sender and delete this > information > from your system. Use, dissemination, distribution, or reproduction of this > transmission > by unintended recipients is not authorized and may be unlawful. > On 15 Dec 2016, at 18:06, Dan Brown wrote: > > > Is anybody still reading this list? > > At least one person. :-) > > > Not sure if my previous post below was clear enough, but if it was > > clear and if it was read, then maybe it's just not concerning enough > > to justify a reply? > > It was clear and not concerning. If an adversary gets access to the > /dev/random interface, that adversary probably has lots of similar > access and therefore much worse things are likely to happen. > > --Paul Hoffman > > > _______________________________________________ > dsfjdssdfsd mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > _______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
