Re: AES cache timing attack
Jerrold Leichter [EMAIL PROTECTED] writes: Usage in first of these may be subject to Bernstein's attack. It's much harder to see how one could attack a session key in a properly implemented system the same way. You would have to inject a message into the ongoing session. I gave an example yesterday. Perhaps you didn't see it. The new 802.11 wireless security protocols encrypt the on-air portion of communications, and are typically attached to ethernet bridges. If you want to, you can send any packet you like at an arbitrary box on the wireless segment from the main network, and have the wireless router act as a fine quality oracle for you for the AES key being used on air. It would be possible, though perhaps less convenient (since it would require tapping rather than just listening) to do something similar to a wide variety of VPN protocols. However, if the protocol authenticates its messages, you'll never get any response to an injected message. You don't need to in the above instances. You just need to be able to inject. People like to downplay the impact of attacks like this, but there are just too many scenarios one didn't think of in the security universe. Doubtless some other usage cases may get badly bitten by AES side channel attacks. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
| It's much harder to see how one could attack a session key in a properly | implemented system the same way. You would have to inject a message into | the ongoing session. However, if the protocol authenticates its messages, | you'll never get any response to an injected message. At best, you might | be able to observe some kind of reaction to the injected message. But | that's a channel that can be made very noisy, since it shouldn't occur | often. (BTW, if you use encrypt-then-authenticate, you're completely | immune to this attack, since the implementation won't ever decrypt the | injected message. Of course, there may be a timing attack against the | *authentication*!) | | I agree with your comments about the injection, but I | don't see why the attack doesn't work on the session | passively. Are you assuming that because it is a | session, it's in some way not plausible to match the | inbound packets with outbound packets? I would | have thought that was possible with things like keep | alives and so forth. The only drawback I can see is | that there might not be enough data (hence desire to | tickle things along with an injection). That's basically it. You need to pair up packets that have known (or at least recognizeable) plaintext - or, more accurately, input to the encryptor. (In CTR mode, what matters is the value of the counter, not the plaintext.) Unless the protocol required some externally-visible response to a keep-alive, it would provide you with no information - *nothing* would pair with the keep- alive packet. (Well, I suppose one can imagine an implementation that uses absolute time on its system to a very high degree of precision to determine when to send a keep-alive, and then posit an attacker who can get access to the system time. But given any reasonably typical keep-alive mechanism, this seems pretty unlikely.) A low-level ack to a received message might work. Any higher-level response - one that came from semantic processing of the actual data, not from the low-level bits - is likely to contain so much noise that pulling useful timing out will take more paired, guesssable packets than an attacker will ever see (yet another reason for periodic rekeying, of course). This does point out some interesting interactions. For example, a mode like CBC is harder to attack because you need to know more actual plaintext to determine the input to the encryptor. On the other hand, a mode like CTR may be particularly vulnerable since the input can be determined independently of the actual plaintext. Pre-whitening, even with a (secret) constant (for a particular connection) - something that generally seems pointless - would help. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] Seagate announces encrypted laptop drives
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 08:07:20 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] Seagate announces encrypted laptop drives Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://arstechnica.com/news.ars/post/20050621-5019.html Ars Technica Seagate announces encrypted laptop drives 6/21/2005 4:02:56 PM, by Eric Bangeman For those reliant on laptops for work, data security can often be an issue, especially if the laptop is stolen. Various third-party encryption tools are available, but Seagate looks to one-up them with its new Hardware-Based Full Disc Encryption (FDE). Slated to begin shipping in 2006, the drives automatically encrypt data as it is written to the drive. Seagate will offer hardware-based full disc encryption technology on its new Momentus FDE family of hard drives, providing the industry's strongest protection against unauthorized access to data on stolen or retired notebook PCs. FDE technology requires only a user key to encrypt all data, not just selected files or partitions, on the drive. FDE uses Triple DES to do the job and will be available on its Momentus 5400 2.5 hard drives for laptops in sizes ranging from 40GB to 120GB. Seagate also claims the drives will have performance identical to other 5400 rpm drives without the built-in encryption. Pricing has not been announced, but expect to pay a premium for the FDE drives. These drives should prove very popular in certain industries, especially with defense contractors and others who deal with sensitive or classified information. Even if a laptop with an FDE drive is stolen or retired without the drives being wiped, the data on there will be unreadable without the user key. Data recovery services will still be able to pull the raw data from drives, although it too will be encrypted. Maybe the IT department over at Los Alamos will invest in a few of these babies-then they won't have to worry if one of their drives disappears. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' ___ Clips mailing list [EMAIL PROTECTED] http://www.philodox.com/mailman/listinfo/clips --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
WYTM - but what if it was true?
A highly aspirated but otherwise normal watcher of black helicopters asked: Any idea if this is true? (WockerWocker, Wed Jun 22 12:07:31 2005) http://c0x2.de/lol/lol.html Beats me. But what it if it was true. What's your advice to clients? iang -- Advances in Financial Cryptography, Issue 1: https://www.financialcryptography.com/mt/archives/000458.html Daniel Nagy, On Secure Knowledge-Based Authentication Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products Ian Grigg, Pareto-Secure - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] dell keylogger
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 14:03:01 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: Re: [Clips] dell keylogger Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] --- begin forwarded text Date: Wed, 22 Jun 2005 09:14:00 -0700 To: R.A. Hettinga [EMAIL PROTECTED] From: Vinnie Moscaritolo [EMAIL PROTECTED] Subject: Re: [Clips] dell keylogger HOAX see http://www.schneier.com/blog/archives/2005/06/dell_keyboard_l.html At 10:53 AM -0400 6/22/05, R.A. Hettinga wrote: --- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 10:51:53 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] dell keylogger Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://c0x2.de/lol/lol.html chromance.de dell keylogger Mirrored by iBabes.org - Babevoting I was opening up my almost brand new Dell 600m laptop, to replace a broken PCMCIA slot riser on the motherboard. As soon as I got the keyboard off, I noticed a small cable running from the keyboard connection underneath a piece of metal protecting the motherboard. ever it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' -- Vinnie Moscaritolo ITCB-IMSH PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042 --- --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' ___ Clips mailing list [EMAIL PROTECTED] http://www.philodox.com/mailman/listinfo/clips --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Optimisation Considered Harmful
A brief altercation this evening with CERT over the recent hyperthread caching issues has brought something that's been simmering at the back of my brain to the forefront. The recent hyperthread/cache key recovery trick, followed by DJB's related (IMO) symmetric key recovery, and preceded by the RSA timing attacks (Boneh et al?) are all examples of attacks on the same thing: optimisation. The problem is that if different paths through your code expose different availability of optimisation, then there's a timing attack available. I predict, for example, that someone will find a way to attack something using pipeline breaks on Pentium processors[1]. How do we fix this? Well, its easy to say: we make everything equally crap - we make sure that all operations are as slow as the slowest possible variant can be. However, on a modern processor, this is _very_ hard to do. Could it be that for safe crypto we should be using Z80s? Cheers, Ben. [1] For those who don't know, even old Pentia have several different processing units internally, which run in parallel. They can even tell when instructions in one's pipeline conflict with another's (e.g. one uses a register as input that another is going to change, but hasn't yet), and delay processing appropriately. However, sometimes they can't work it out (this is, of course, another optimisation, this time for transistor count) and so they just throw their hands up, stop all the pipelines and start again. This causes a _substantial_ delay, easily measurable - I know of loops of tens of instructions that go twice as fast if apparently redundant - but pipeline-intelligence-informing - instructions are inserted. Of course, the PowerPCs with their speculative execution are probably even more fun in this respect (do they still do that?). -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
Allan Liska wrote: 3. Use an on-screen keyboard. For extra points, try Dasher. http://www.inference.phy.cam.ac.uk/dasher/ -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
