From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, tytso@mit.edu
Cc: linux-kernel@vger.kernel.org, price@mit.edu
Subject: Re: Replace /dev/random input mix polynomial with Brent's xorgen?
Date: 16 Dec 2013 10:03:15 -0500 [thread overview]
Message-ID: <20131216150315.4746.qmail@science.horizon.com> (raw)
In-Reply-To: <20131216064359.GB28544@thunk.org>
> I understand that; and as I wrote in my last e-mail, I think that is a
> substantially harder attack than the currently published cache timing
> attacks, which are chosen plaintext attacks --- that is the attacker
> doesn't know the key, but can choose the plaintext, and view the
> resulting ciphertext.
Okay, sorry for the misunderstanding. I *thought* we were talking past
each other.
First of all, you might want to look at this paper:
http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper031.pdf
"Cache Games -- Bringing Access-Based Cache Attacks on AES to Practice"
It describes a practical implementation of a timing-based key-recovery
attack *without any access to plain- or ciphertext at all* after watching
~100 block encryptions in OpenSSL.
Key recovery is the target usually studied, so recovering the text
(in the absence of the key or other text) is not as well documented,
but it certainly shouldn't be any harder.
The major complicating factor is that most attacks assume a constant key,
while hashing uses a varying key per encryption. But there are strong
dependencies (the output of one encryption is the input to the next)
that can perhaps be handled with improved analysis.
No, I don't have example code, but I hope you can see how I think
concerns are realistic. (And remember: attacks only ever get better.)
(I should also mention that the paper above exploits the Linux scheduler
to collect high-resolution timing information, so could be greatly
hampered by disabling preemption in /dev/random. But there is probably
an equivalent attack via hyperthreading.)
As I've said before, the point I want to stress is not even that the
attack is necessarily practical, but it's a PITA to prove that it's *not*,
and the SHA-3 competition has given us several excellent cryptographic
cores explicitly designed to avoid the issue entirely.
If the alternatives to AES had serious disadvantages, I'd be getting busy
with a detailed comparison. But is that even necessary?
next prev parent reply other threads:[~2013-12-16 15:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-14 9:06 Replace /dev/random input mix polynomial with Brent's xorgen? George Spelvin
2013-12-14 19:23 ` Theodore Ts'o
2013-12-14 21:55 ` George Spelvin
2013-12-15 2:21 ` Theodore Ts'o
2013-12-15 8:34 ` George Spelvin
2013-12-15 22:19 ` Theodore Ts'o
2013-12-16 4:22 ` George Spelvin
2013-12-16 6:43 ` Theodore Ts'o
2013-12-16 6:49 ` Theodore Ts'o
2013-12-16 15:03 ` George Spelvin [this message]
2013-12-15 20:03 ` Greg Price
2013-12-15 22:09 ` George Spelvin
2013-12-16 0:32 ` Greg Price
2013-12-16 6:53 ` George Spelvin
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=20131216150315.4746.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=price@mit.edu \
--cc=tytso@mit.edu \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox