Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
- Forwarded message from Matt Mackall m...@selenic.com - Date: Thu, 11 Jul 2013 17:34:48 -0500 From: Matt Mackall m...@selenic.com To: liberationtech liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Heml.is - The Beautiful Secure Messenger X-Mailer: Evolution 3.4.4-1 Reply-To: liberationtech liberationt...@lists.stanford.edu On Thu, 2013-07-11 at 13:47 -0700, Andy Isaacson wrote: Linux now also uses a closed RdRand [2] RNG if available. There was a bunch of churn when this code went in, so I could be wrong, but I believe that RdRand is only used to stir the same entropy pool as all of the other inputs which are used to generate random data for /dev/random et al. It's hard to leverage control of one input to a random pool into anything useful. It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. From a quick skim of current sources, much of that has recently been rolled back (/dev/random, notably) but kernel-internal entropy users like sequence numbers and address-space randomization appear to still be exposed to raw RdRand output. (And in the meantime, my distrust of Intel's crypto has moved from standard professional paranoia to actual legitimate concern.) -- Mathematics is the supreme nostalgia of our time. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
On 2013-07-13 12:20 AM, Eugen Leitl wrote: It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. Is there a plausible rationale for bypassing the entropy pool? How unauditable is RdRand? Is RdRand unauditable because it uses magic instructions that do unknowable things? Is it designed to actively resist audit? Has Intel gone out of its way to prevent you from knowing how good their true random generation is? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald jam...@echeque.com wrote: On 2013-07-13 12:20 AM, Eugen Leitl wrote: It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. Is there a plausible rationale for bypassing the entropy pool? Throughput? Not bypassing means having to wait until enough randomness has been gathered from trusted sources. Or maybe it's just trusting Intel and assuming that RDRAND provides better randomness. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
On 12/07/13 21:54 PM, Patrick Mylund Nielsen wrote: On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2013-07-13 12:20 AM, Eugen Leitl wrote: It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. Is there a plausible rationale for bypassing the entropy pool? Throughput? Not bypassing means having to wait until enough randomness has been gathered from trusted sources. Typically, the entropy pool is used to feed a PRNG. Throughput isn't really an issue because modern PRNGs are fast, and there are very few applications that require psuedo-RNs at that sort of speed. Or maybe it's just trusting Intel and assuming that RDRAND provides better randomness. This thread has been seen before. On-chip RNGs are auditable but not verifiable by the general public. So the audit can be done then bypassed. Which in essence means the on-chip RNGs are mostly suitable for mixing into the entropy pool. Not to mention, Intel have been in bed with the NSA for the longest time. Secret areas on the chip, pop instructions, microcode and all that ... A more interesting question is whether the non-USA competitors are also similarly friendly. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
[BTW, when responding to a message forwarded, do please fix the quote attribution.] On Fri, Jul 12, 2013 at 2:29 PM, ianG i...@iang.org wrote: This thread has been seen before. On-chip RNGs are auditable but not verifiable by the general public. So the audit can be done then bypassed. Which in essence means the on-chip RNGs are mostly suitable for mixing into the entropy pool. Not to mention, Intel have been in bed with the NSA for the longest time. Secret areas on the chip, pop instructions, microcode and all that ... A more interesting question is whether the non-USA competitors are also similarly friendly. I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. I would hope that talented folks at the NSA would be averse to embedding backdoors in hardware (and firmware, and software) that they could lose control of, especially in light of recent developments. I'm *not* saying that my wishing is an argument for trusting Intel's RNG -- I'm sincerely trying to understand what attacks could conceivably be mounted through a suitably modified RDRAND with low systemic risk. For example, there might be a way to close a backdoor in a hurry, should it leak. Understanding the attacks that sigint agencies might mount in this fashion might help us understand the likelihood of their attempting them. I think it's important to highlight the systemic risk caused by embedding backdoors everywhere. See Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP, by Bellovin, Blaze, et. al. Systemic failures can be extremely severe. The 2008 financial crisis was a systemic failure, and, sadly, I can imagine far worse systemic failures. Minimizing systemic risk should be a key policy goal in general, but management of systemic risk is inherently not in the interests of any short-term political actors, therefore it's important to ensure institutional inertia for systemic risk minimization. The NSA that once worked to strengthen DES against differential cryptanalysis clearly thought so (or, rather, the people who made that happen did) -- is today's NSA no longer interested in the nation's civilian and military security?! Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
I think compromising microcode update signing keys would be the easiest path. Then you don't need backdoors baked in the hardware, don't need Intel's buy-in, and can target specific systems without impacting the public at large. This is a pretty interesting analysis showing that these updates are 2048-bit RSA signed blobs: http://inertiawar.com/microcode/ On Fri, Jul 12, 2013 at 1:38 PM, Nico Williams n...@cryptonector.comwrote: I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
I would hope that talented folks at the NSA would be averse to embedding backdoors in hardware (and firmware, and software) that they could lose control of, especially in light of recent developments. Unfortunately it appears that for security reasons at least some chips are being backdoored. For instance see Breakthrough silicon scanning discovers backdoor in military chip. The chip designers have admitted in that case that the backdoor was designed as part of the security scheme. Actel inserted the backdoor, I would assume with NSA permission since backdooring sensitive chips without NSA permission would be extremely risky. The NSA that once worked to strengthen DES against differential cryptanalysis clearly thought so (or, rather, the people who made that happen did) -- is today's NSA no longer interested in the nation's civilian and military security?! But remember that the NSA weakened DES by reducing the key size from 128 bits to 54 bits. It appears that the preferred the ability to break DES to issues of civil security even back then. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
Nico Williams n...@cryptonector.com writes: I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. Right. How exactly would you backdoor an RNG so (a) it could be effectively used by the NSA when they needed it (e.g. to recover Tor keys), (b) not affect the security of massive amounts of infrastructure, and (c) be so totally undetectable that there'd be no risk of it causing a s**tstorm that makes the $0.5B FDIV bug seem like small change (not to mention the legal issues, since this one would have been inserted deliberately, so we're probably talking bet- the-company amounts of liability there). I'm *not* saying that my wishing is an argument for trusting Intel's RNG -- I'm sincerely trying to understand what attacks could conceivably be mounted through a suitably modified RDRAND with low systemic risk. Being careful is one thing, being needlessly paranoid is quite another. There are vast numbers of issues that crypto/security software needs to worry about before getting down to has Intel backdoored their RNG. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
There are plenty of ways to design an apparently random number generator so that you can predict the output (exactly or approximately) without causing any obvious flaws in the pseudorandom output stream. Even the smallest bias can significantly reduce security. This could be a critical failure, and we have no way to determine whether or not it is happening. As for preventing potential security holes and making the backdoor deniable, that takes a little more thinking. And for legal issues, there are any number of hand-wavy blame-shifting schemes that Intel and whoever would want to backdoor their RNG could use. I contest the idea that we should ignore the fact that Intel's RNG could be backdoored. Just because other problems exist doesn't mean we should ignore this one. I agree that perhaps worrying about this constitutes being too paranoid, but no cryptographer ever got hurt by being too paranoid, and not trusting your hardware is a great place to start. On Fri, Jul 12, 2013 at 7:20 PM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: Nico Williams n...@cryptonector.com writes: I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. Right. How exactly would you backdoor an RNG so (a) it could be effectively used by the NSA when they needed it (e.g. to recover Tor keys), (b) not affect the security of massive amounts of infrastructure, and (c) be so totally undetectable that there'd be no risk of it causing a s**tstorm that makes the $0.5B FDIV bug seem like small change (not to mention the legal issues, since this one would have been inserted deliberately, so we're probably talking bet- the-company amounts of liability there). I'm *not* saying that my wishing is an argument for trusting Intel's RNG -- I'm sincerely trying to understand what attacks could conceivably be mounted through a suitably modified RDRAND with low systemic risk. Being careful is one thing, being needlessly paranoid is quite another. There are vast numbers of issues that crypto/security software needs to worry about before getting down to has Intel backdoored their RNG. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
On Sat, Jul 13, 2013 at 1:38 AM, William Yager will.ya...@gmail.com wrote: not trusting your hardware is a great place to start. Heh, might as well just give up. http://cm.bell-labs.com/who/ken/trust.html (I know what you meant, just couldn't resist.) On Fri, Jul 12, 2013 at 7:20 PM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: Nico Williams n...@cryptonector.com writes: I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. Right. How exactly would you backdoor an RNG so (a) it could be effectively used by the NSA when they needed it (e.g. to recover Tor keys), (b) not affect the security of massive amounts of infrastructure, and (c) be so totally undetectable that there'd be no risk of it causing a s**tstorm that makes the $0.5B FDIV bug seem like small change (not to mention the legal issues, since this one would have been inserted deliberately, so we're probably talking bet- the-company amounts of liability there). I'm *not* saying that my wishing is an argument for trusting Intel's RNG -- I'm sincerely trying to understand what attacks could conceivably be mounted through a suitably modified RDRAND with low systemic risk. Being careful is one thing, being needlessly paranoid is quite another. There are vast numbers of issues that crypto/security software needs to worry about before getting down to has Intel backdoored their RNG. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
