Re: [dsfjdssdfsd] dsfjdssdfsd Digest, Vol 9, Issue 1

[Prashant Sinha <[e-mail]>]

Not sure how I missed it, but yeah, least I read the thread.

-Prashant


On 16 December 2016 at 08:13:13, [e-mail]
([e-mail]) wrote:
> Send dsfjdssdfsd mailing list submissions to
> [e-mail]
>
> 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
> [e-mail]
>
> You can reach the person managing the list at
> [e-mail]
>
> 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: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
>