4 ms·
Stuff like this blows my mind. I am still not entirely clear on how they are able to extract the key (does the victim computer need to process the provided enc
by sbarre 11y ago
Stuff like this blows my mind.
I am still not entirely clear on how they are able to extract the key (does the victim computer need to process the provided encrypted payload? So if the victim never does that, they can't steal the key?), but it's still a fascinating read.
- steckerbrett 11y agoOften this sort of leakage comes down to timing, you can infer what a person is doing by the amount of time it takes you to do something. In the simplest example (and only slightly related to the linked article), imagine we have an API end point that allows you to log in using a password. A naive implementation of authentication might look like this: if ( password = "hunter2" ): return True This in a lot of cases will be vulnerable to a timing attack. If the user submits the password "huntducks" it will take the function momentarily longer to return than if they had submitted "whalehorn", due to the underlying comparison exiting at the first non-match. With a bit of trial and error they can deduce the password one character at a time by altering their guess to take longer and longer to execute. To avoid this security sensitive code needs to be time constant, which is a lot harder than you'd imagine. Attacks like the author are performing are a lot more complicated and use tricks like coercing the victim into signing distinctive plaintexts, but the example also works for more complex systems like ECDSA where people can derive the signing key by just knowing how long it took.
- davnicwil 11y agoVery interesting, and something I'd never considered before. Instead of going to the effort of making the function run in a constant time, might adding a small random delay before it returns also mitigate against this type of attack?
- dustcoin 11y agoThe noise could be filtered out with enough samples, so this mitigation only increases the number of attempts required and does not prevent the attack.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- briholt 11y agoBest practice is to hash the password. This is good for a lot of reasons, one of which is that the time to compare hash("hunter") vs hash("hunter2") vs hash("hunter21") does not correlate in any meaningful way. https://en.wikipedia.org/wiki/Hash_function https://en.wikipedia.org/wiki/Hash_function
- Dylan16807 11y agoAnd it gets even worse than that, in certain environments the fact that it takes more energy to flip a transistor than to keep it on the same output can leak information. Noise technically mitigates, but it's like covering your unlocked safe with a cardboard box.
- drewcrawford 11y agoThis is a chosen ciphertext attack, so yes, you have to decrypt the attacker-provided payload. That being the case, there are a lot of systems where that is easy to achieve. If you have GPG in your mail client, it will decrypt anything anybody sends you. Another thing to keep in mind is that attacks always get better, they never get worse. So today's chosen ciphertext attack is tomorrow's zero-knowledge attack.
- god_bless_texas 11y agoyep, remember when we used to "air-gap" computers for safety?
- steckerbrett 11y agoA lead gap might be a better term.
- mafuyu 11y agoYou may be interested in this episode of The Amp Hour podcast, where they talk about powerline analysis attacks: http://www.theamphour.com/239-an-interview-with-colin-oflynn-aspirated-adamantine-attacks/ http://www.theamphour.com/239-an-interview-with-colin-oflynn.... In general, it is like many other side channel attacks, where you can use the data to put constraints on the search space for a brute force attack.
- sbarre 11y agoThanks a lot! This looks great!