From: "Theodore Y. Ts'o" <firstname.lastname@example.org> To: Pavel Machek <email@example.com> Cc: Linus Torvalds <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, "Ahmed S. Darwish" <firstname.lastname@example.org>, LKML <email@example.com>, Nicholas Mc Guire <firstname.lastname@example.org>, the arch/x86 maintainers <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, Kees Cook <email@example.com> Subject: Re: x86/random: Speculation to the rescue Date: Mon, 7 Oct 2019 07:47:34 -0400 [thread overview] Message-ID: <20191007114734.GA6104@mit.edu> (raw) In-Reply-To: <20191006182103.GA2394@amd> On Sun, Oct 06, 2019 at 08:21:03PM +0200, Pavel Machek wrote: > Even without cycle counter... if we _know_ we are trying to generate > entropy and have MMC available, we don't care about power and > performance. > > So we can just... > > issue read request on MMC > while (!interrupt_done) > i++ > > ...and then use i++ as poor man's version of cycle counter. I suggest that you try that and see how much uncertainty you really have before you assume that this is actually going to work. Again, on "System on a Chip" systems, there is very likely a single master oscillator, and the eMMC is going to be on the the same silicon die as the CPU. At least for spinning rust platters it's on a physically separate peripheral, and there was a physical claim about how chaotic air turbulence might add enough uncertainty that timing HDD reads could be unpredictable (although note that the paper which claimed this was written 25 years ago, and HDD's have had to get more precise, not less, in order to cram more bits into the same squire millimeter). more.)  D. Davis, R. Ihaka, P.R. Fenstermacher, "Cryptographic Randomness from Air Turbulence in Disk Drives", in Advances in Cryptology -- CRYPTO '94 Conference Proceedings, edited by Yvo G. Desmedt, pp.114--120. Lecture Notes in Computer Science #839. Heidelberg: Springer-Verlag, 1994 But for a flash device that is on the same silicon as the CPU, and driven off of the same clock crystal, and where you are doing *reads*, so you can't even depend on SSD GC and uncertainties in programming the flash cell --- I'm going to be dubious. If someone wants to use this as a last ditch hope, then we can let systemd do this, where there's at least a bit more uncertainty in userspace, and maybe you could be doing something useful, like running fsck on the stateful partitions of the system. Ultimately, though, we really want to try to get a hardware RNG, and for that matter, a cryptographic secure element built into these devices, and the sooner we can pound it into CPU manufacturers' heads that not doing this should be professional malpractice, the better. - Ted P.S. Note that this Don Davis's paper claims that they were able to extract 100 independent unpredictable bits per _minute_. Given that modern init scripts want us to be able to boot in under a few seconds, and we need at least 128 independent bits to securely initialize the CRNG, people who think that we can get secure random bits suitable for long-term cryptographic keys (say, such as initializing the host's SSH key) during early boot based only on HDD timings may be a bit.... optimistic. P.P.S. I actually knew Don; he was at MIT Project Athena as a staff member at the same time I was working on Kerberos as my day job, and Linux's e2fsprogs, /dev/random, etc. as a hobby...
next prev parent reply other threads:[~2019-10-07 11:48 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-28 22:24 Thomas Gleixner 2019-09-28 23:53 ` Linus Torvalds 2019-09-29 7:40 ` Thomas Gleixner 2019-09-29 8:05 ` Alexander E. Patrakov 2019-09-30 1:16 ` Linus Torvalds 2019-09-30 2:59 ` Linus Torvalds 2019-09-30 6:10 ` Borislav Petkov 2019-09-30 16:06 ` Linus Torvalds 2019-10-01 13:51 ` Borislav Petkov 2019-10-01 17:14 ` Linus Torvalds 2019-10-01 17:50 ` [PATCH] char/random: Add a newline at the end of the file Borislav Petkov 2019-09-30 18:05 ` x86/random: Speculation to the rescue Kees Cook 2019-09-30 3:37 ` Theodore Y. Ts'o 2019-09-30 13:16 ` Theodore Y. Ts'o 2019-09-30 16:15 ` Linus Torvalds 2019-09-30 16:32 ` Peter Zijlstra 2019-09-30 17:03 ` Linus Torvalds 2019-10-01 10:28 ` David Laight 2019-10-15 21:50 ` Thomas Gleixner 2019-10-01 16:15 ` Ahmed S. Darwish 2019-10-01 16:37 ` Kees Cook 2019-10-01 17:18 ` Ahmed S. Darwish 2019-10-01 17:25 ` Linus Torvalds 2019-10-06 12:07 ` Pavel Machek 2019-10-02 12:01 ` Theodore Y. Ts'o 2019-10-06 11:41 ` Pavel Machek 2019-10-06 17:26 ` Linus Torvalds 2019-10-06 17:35 ` Pavel Machek 2019-10-06 18:06 ` Linus Torvalds 2019-10-06 18:21 ` Pavel Machek 2019-10-06 18:26 ` Linus Torvalds 2019-10-07 11:47 ` Theodore Y. Ts'o [this message] 2019-10-07 22:18 ` Pavel Machek 2019-10-08 11:33 ` David Laight 2019-10-09 8:02 ` Pavel Machek 2019-10-09 9:37 ` David Laight 2019-10-01 2:14 hgntkwis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191007114734.GA6104@mit.edu \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: x86/random: Speculation to the rescue' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).