![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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. 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.<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. In for a penny, in for a = pound.</div><div><div><div> = = = -- 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 |