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

Prashant Sinha <prashantinq@gmail.com> Fri, 16 December 2016 08:47 UTC

Return-Path: <prashantinq@gmail.com>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE51129ACE for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 16 Dec 2016 00:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVZqhE_7HB66 for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 16 Dec 2016 00:47:00 -0800 (PST)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F780129AC7 for <dsfjdssdfsd@ietf.org>; Fri, 16 Dec 2016 00:47:00 -0800 (PST)
Received: by mail-qk0-x241.google.com with SMTP id h201so10550953qke.3 for <dsfjdssdfsd@ietf.org>; Fri, 16 Dec 2016 00:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :content-transfer-encoding; bh=bRGb9Gizp80mTTufReFGiQOnKJUaXQVeFA6kSfgkrSg=; b=WzXJt0sOqCWszhJA9IHbn8Kd6dPQeozGq1UI5Bq+b1oQcmwSIHfflxaNgECgzXReTt mKL2RDBg2P20pSpCL3V3Iqxrmdbti3+agaB5WZIYlolnVx84SHHGvI5TcaPpg1HmTI6+ 5e8jLtumT2o6l1OiJa6f/8jFVKc57ZtWdHECy4ZHdw4MZIv307Eu8481iBwgYXzq+9Kh dBazLkgjeCKVAzNS8/jOXz/mjTR3pHvpnO9blsuSEzY/TJpjNXrR9Sr6FWBMds0Nz9g1 xwzqGBeDZjH/Y3ZRIzaoyWMrjb5Gruy8f7KPOIa5PnL0+jrGdy/Gdfy5/8WzKfS+e71K /X8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:content-transfer-encoding; bh=bRGb9Gizp80mTTufReFGiQOnKJUaXQVeFA6kSfgkrSg=; b=lrkljZ+1Pngz03GyLwMWMbmAxPX1hMjK4ogRr4dxEEx01O4/TzpmwScB0c6Op8Whyu C6hEXtf0jlXC3LfumtUVpqp8Qgqx3Vuj54nY/3LSs2rUKSCAzpP4kWriqlGXUABi5tc5 /GA3uAGbVDt6PT9uUjRn/aIUDRV1l4SqeWGn7X2i54tR/lOpsWsGekgqHhHFoUlBQwoh cg299sBUm5SVkyVrlqj2QljVdazGg0+f64n4DepOENs1SfaKxzSaAldkg0auAJ1OoFA8 J9lfjU8xjHiRC5iyK4uaaRFQtKREcSSAbSNLr9EtXrqShjRC4qHeQfFV0s+nk1Rzouhb sr5w==
X-Gm-Message-State: AIkVDXLEdz6aEajgZ6TcU3bcirQPOwDW9n/2pyIlld+1cTS8TK6H88eNZcHspWkdd/SPF8tnJl5xzCVa4hMihw==
X-Received: by 10.55.102.138 with SMTP id a132mr1478538qkc.57.1481878019196; Fri, 16 Dec 2016 00:46:59 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Dec 2016 00:46:58 -0800
From: Prashant Sinha <prashantinq@gmail.com>
In-Reply-To: <mailman.2638.1481856178.5430.dsfjdssdfsd@ietf.org>
References: <mailman.2638.1481856178.5430.dsfjdssdfsd@ietf.org>
X-Mailer: Airmail (397)
MIME-Version: 1.0
Date: Fri, 16 Dec 2016 00:46:58 -0800
Message-ID: <CAFMV-sjzbUCZDfjy61tudpdRQQFLpEwmuJMDH+m_tsf8V5Zviw@mail.gmail.com>
To: dsfjdssdfsd@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/B-OPWBCHd4v5LN7NU4UUbAF3zX8>
X-Mailman-Approved-At: Fri, 16 Dec 2016 07:57:53 -0800
Subject: Re: [dsfjdssdfsd] dsfjdssdfsd Digest, Vol 9, Issue 1
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dsfjdssdfsd/>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 13:21:46 -0000

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

-Prashant


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