[148789] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] On Security Architecture, The Panopticon,

daemon@ATHENA.MIT.EDU (Jerry Leichter)
Sat Dec 28 10:44:26 2013

X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <CAAt2M19Soh=EP1Cjem9RxLG4F9WwiVeC57PRdcAk6Qzw3Gacpw@mail.gmail.com>
Date: Sat, 28 Dec 2013 01:05:12 -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


--===============8110326152797801981==
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D96E265-D197-43E7-8A40-98D90AAA512E"


--Apple-Mail=_3D96E265-D197-43E7-8A40-98D90AAA512E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Dec 27, 2013, at 2:42 PM, Natanael wrote:
> @Jerry: Why not just use timing alone? If you make the device add =
"random" delays that look natural on the network, then you could encode =
data in the timing differences. The data would be hidden in the timing =
noise and could even require a key to decode so that even somebody who =
knows of the timing encoding scheme can't decode it without the key.
>=20
[I assume this was on the topic of a hardware AES implementation - or a =
hardware hack that recognized software AES - leaking key bits.]
Maybe there are circumstances in which this could be done, but I don't =
see it as likely in most.  The encryption is just too far removed from =
the network transactions.  Suppose you had control of the AES =
implementation that fed data into a TCP socket.  Could you really =
produce the kinds of variations in TCP timing that someone could detect? =
 If the encryption was right at the Ethernet packet level, sure, you =
could easily slip data into the inter-packet timing information.  But =
doing it "looking through" the whole TCP stack?  I don't know.

Now, if you want to consider about *multiple* hacks into the hardware - =
one to grab the key from AES, the other to leak the grabbed information =
through manipulation at the packet level - you might have something.  In =
for a penny, in for a pound.
                                                        -- Jerry


--Apple-Mail=_3D96E265-D197-43E7-8A40-98D90AAA512E
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 27, 2013, at 2:42 PM, Natanael =
wrote:</div><blockquote type=3D"cite"><p dir=3D"ltr">@Jerry: Why not =
just use timing alone? If you make the device add "random" delays that =
look natural on the network, then you could encode data in the timing =
differences. The data would be hidden in the timing noise and could even =
require a key to decode so that even somebody who knows of the timing =
encoding scheme can't decode it without the key. </p></blockquote>[I =
assume this was on the topic of a hardware AES implementation - or a =
hardware hack that recognized software AES - leaking key =
bits.]</div>Maybe there are circumstances in which this could be done, =
but I don't see it as likely in most. &nbsp;The encryption is just too =
far removed from the network transactions. &nbsp;Suppose you had control =
of the AES implementation that fed data into a TCP socket. &nbsp;Could =
you really produce the kinds of variations in TCP timing that someone =
could detect? &nbsp;If the encryption was right at the Ethernet packet =
level, sure, you could easily slip data into the inter-packet timing =
information. &nbsp;But doing it "looking through" the whole TCP stack? =
&nbsp;I don't know.<div><br></div><div>Now, if you want to consider =
about *multiple* hacks into the hardware - one to grab the key from AES, =
the other to leak the grabbed information through manipulation at the =
packet level - you might have something. &nbsp;In for a penny, in for a =
pound.</div><div><div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; -- Jerry</div></div><div><br></div></div></body></html>=

--Apple-Mail=_3D96E265-D197-43E7-8A40-98D90AAA512E--

--===============8110326152797801981==
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
--===============8110326152797801981==--

home help back first fref pref prev next nref lref last post