[148790] in cryptography@c2.net mail archive
Re: [Cryptography] On Security Architecture, The Panopticon,
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Sat Dec 28 10:45:13 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <CAAt2M1-no0NZVL4qm-4U4uiCzpLk+hN2WaFi1BNzfjpYFoN9GA@mail.gmail.com>
Date: Sat, 28 Dec 2013 07:27:19 -0500
To: Natanael <natanael.l@gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>, ianG <iang@iang.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6550805620748383322==
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6C4CB0A-D02B-4557-B438-1EF1454BEB3C"
--Apple-Mail=_C6C4CB0A-D02B-4557-B438-1EF1454BEB3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Dec 28, 2013, at 3:35 AM, Natanael wrote:
> Or how about timing based leaks triggered by a specific type of =
slightly malformed data package? You could then make the timing =
differences far larger and nobody would realize what is happening.
>=20
I don't understand what you're suggesting.
Let's review where we are. The opening question here was: Should we be =
concerned about an attack in which the hardware recognizes that an AES =
encryption is being done? My suggestion was that that recognizing when =
this was happening would be a hard problem, probably an insoluble one =
except in specialized circumstances. But let's grant it and go a step =
further: Assume an hardware assist for AES, so that the hardware =
doesn't even have to solve that problem. I then suggested that we are =
then at a next level of problem: What should the hardware *do*? I =
suggested the only thing it really *could* do was exfiltrate the =
captured key. Which led us here.
What I'll suggest at this point is that the "exfiltrate some information =
undetectably" problem is difficult. Yes, it can probably be solved by =
an attacker - but given a system on which the attacker has solved this =
problem, the game is over. There's not much point in looking at fancy =
ways to pick up more information - the system's already fully =
compromised. For example, it was long ago pointed out (I forget by who) =
that a search of memory for "high-entropy" 128-bit blocks works pretty =
well for finding stored keys. Much easier than playing with the details =
of AES, and it finds keys even when they aren't in active use.
-- Jerry
--Apple-Mail=_C6C4CB0A-D02B-4557-B438-1EF1454BEB3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Dec 28, 2013, at 3:35 AM, Natanael =
wrote:</div><blockquote type=3D"cite"><p dir=3D"ltr">Or how about timing =
based leaks triggered by a specific type of slightly malformed data =
package? You could then make the timing differences far larger and =
nobody would realize what is happening. </p></blockquote>I don't =
understand what you're suggesting.</div><div><br></div><div>Let's review =
where we are. The opening question here was: Should we be =
concerned about an attack in which the hardware recognizes that an AES =
encryption is being done? My suggestion was that that recognizing =
when this was happening would be a hard problem, probably an insoluble =
one except in specialized circumstances. But let's grant it and go =
a step further: Assume an hardware assist for AES, so that the =
hardware doesn't even have to solve that problem. I then suggested =
that we are then at a next level of problem: What should the =
hardware *do*? I suggested the only thing it really *could* do was =
exfiltrate the captured key. Which led us =
here.</div><div><br></div><div>What I'll suggest at this point is that =
the "exfiltrate some information undetectably" problem is difficult. =
Yes, it can probably be solved by an attacker - but given a system =
on which the attacker has solved this problem, the game is over. =
There's not much point in looking at fancy ways to pick up more =
information - the system's already fully compromised. For example, =
it was long ago pointed out (I forget by who) that a search of memory =
for "high-entropy" 128-bit blocks works pretty well for finding stored =
keys. Much easier than playing with the details of AES, and it =
finds keys even when they aren't in active use.</div><div><div> =
=
=
-- =
Jerry</div><div><br></div></div>
</body></html>=
--Apple-Mail=_C6C4CB0A-D02B-4557-B438-1EF1454BEB3C--
--===============6550805620748383322==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============6550805620748383322==--
