5 ms·

Ask HN: Paired USB keys for 100% unbreakable encryption?

9 points by heeton 13y ago

Just a thought: * 2 USB keys that share a securely generated amount of random data. * Share one with somebody you'd like to communicate with. * The two keys can encrypt/decrypt messages to each other using that random data as a one-time-pad. http://en.wikipedia.org/wiki/One-time_pad * You can then transmit messages across the net in plaintext. You can even tell your partner which part of the pad you are using. Technically, one-time-pads are impossible to crack. You'd only have to watch out for observation attacks and that sort of thing (perhaps the keys would could be bootable for extra security?). The keys would only work for a certain amount of time before needing to be "paired" again, their pad data would eventually run out. But with modern keys holding many GB of data, this would take a while. Obviously this is only for the super-paranoid (or the geeks) who want to chat 100% securely among friends. But hey, 6 months ago only the super-paranoid were using encryption at all and look where we are now.

zxcvgm 13y ago
That kinda sounds like iTwin http://www.itwin.com/ http://www.itwin.com/ It comes in a pair with 2 USB ends and can be mated together to share a key.
- heeton 13y ago
  Yep :) Spot on, need to buy one of those. Good to know someone is doing this!
TheLoneWolfling 13y ago
You can do this already - just take two flash drives and mirror the same random data to each one. Just make sure you never use the same part of the random data twice. Of course, I have to ask: why bother? If you're giving them a flash drive anyways, just exchange public keys. Also safer, as if someone loses/etc. a public key it's no big deal whereas if someone loses the OTP then all of the data you sent is trivially decryptable.
- heeton 13y ago
  Yea techies can do it but it's not simple/easy to use. I couldn't give my mother a key to use. I suppose something about the pure security of a OTP is enticing. Public keys can be broken, it's just not feasible at the moment. I don't know enough here, but it seems like past data sent via public key will eventually be trivial to decrypt? Losing a OTP is equivalent to losing a private key, not much changes there. I suppose if your partner was "coerced" then a OTP exposes both sides of the transaction, whereas knowing their private key would only help decrypt your messages to them.
vmarsy 13y ago
In theory yes, but if you're super-paranoid good luck to find "a securely generated amount of random data."
- heeton 13y ago
  Seeding a PRNG with user entry? Thermal noise from a component in the key?
  - tptacek 13y ago
    Congratulations, you just reinvented the "stream cipher".
fernly 13y ago
I don't understand "You can then transmit messages... in plaintext." A message composed of SERHYTVXA etc is obviously encrypted. But another question: by how much is the system weakened if the pad data is nonrandom? Because I was thinking how much simpler the key exchange would be, if instead of sharing pad-texts, you only shared links to texts that were available on the internet -- both parties to use as a pad the text of a particular Google Book, or Internet Encyclopedia of Philosophy article.[edit below] Another option would be share only a "persistent identifier" to be used with [0]. [0] http://www.random.org/integers/?mode=advanced http://www.random.org/integers/?mode=advanced [edit] clearly you would not want to access the pad at any time near to transmitting a message encoded with that pad! You would download the pad data at some other time, preferably with another ID.
- Ellipsis753 13y ago
  If the pad data can be worked out or is known then the "encryption" is useless. If you use something like a book and the book used is unknown then it could still be found if someone can work out part of your message though guess work. "They sent a 5 letter word, I'm guessing it was "hello" therefore the first part of the book they used must be........". If you send the pad across the internet at all it could be recorded at many points along the way. While it still might not be cracked you'd certainly do better using proper encryption.
tptacek 13y ago
No professional or academic cryptographer in the world does this. Consider asking yourself why. It isn't because they haven't heard of a one-time pad. When Schneier wrote about one-time pads in Applied Cryptography, he wasn't doing it to establish the high water mark for best possible crypto; he was doing it to illustrate some of the theory that underpins modern ciphers. Unfortunately, a whole generation of amateur cryptographers took a different message away: "forget about modern block ciphers, let's just use one-time pads". Encrypt your content with AES-128 with a random (from /dev/random) key; write the key down as 32 hexadecimal digits. Nobody is going to break it, ever.
- sillysaurus2 13y ago
  Encrypt your content with AES-128 with a random (from /dev/random) key; write the key down as 32 hexadecimal digits. Nobody is going to break it, ever. There are caveats. Don't reuse your key, because if an attacker can trigger your AES encryption on demand, and you're reusing the same key, then the attacker can break your encryption after alarmingly few operations. https://dl.dropboxusercontent.com/u/315/articles/Cache%20Attacks%20and%20Countermeasures%20-%20the%20Case%20of%20AES%20%5BShamir%2C%202005%5D.pdf https://dl.dropboxusercontent.com/u/315/articles/Cache%20Att... (That's a different situation than "write down the key," but we're throwing around ideas in this thread, so I just wanted to make sure everyone knows not to write software that can be triggered on-demand to AES encrypt some content with an unchanging key. I could imagine someone being tempted to write a chat program like that, and an attacker will rip its security to shreds using sidechannel attacks.)
  - tptacek 13y ago
    That's not actually what that paper says. It says that if your AES implementation relies on secret-derived table lookups and your attacker shares a machine with you, they can write a spy process that will profile the local cache and from that trace data infer the table lookups you did. It's a great (and famous) paper, but it does not suggest that reusing an AES key is dangerous, because of course it isn't. The guy talking about using USB one-time pads is not in a good position to be concerned about mitigating localhost attackers.
DanBC 13y ago
OTPs feel nice because "UNBREAKABLE!!". But there are severe problems. 1) The pad needs to be random. It must only be used once. It must be larger than the plain text you want to send. 2) You have to be able to transmit the pad somehow. If you can transmit the pad, why don't you just transmit the message, or transmit keys? People do sell OTP technology. It's up to you to decide if it's snake oil or not. (http://www.mils.com/en/products/unified-communication/#2 http://www.mils.com/en/products/unified-communication/#2) (http://cipher-text.blogspot.co.uk/2005/08/one-time-pads-on-paper-tape-in-2005.html http://cipher-text.blogspot.co.uk/2005/08/one-time-pads-on-p...) > First, they were founded in 1946, and have been doing one-time pads ever since. Second, they seem to be pitching their products at governments. Third, amongst other things, their random number generator can output to a...wait for it...5-channel paper tape puncher (pictured above left). > 5-channel paper tape -- as in, pretty much the same one-time pad implementation Gilbert Vernam patented in 1919. I'm flabbergasted. Who's still using this stuff? I reckon you'd need a little over 4 meters for each kilobyte of information you encrypt.

sillysaurus2 13y ago

I'm trying to figure out how my understanding of the paper went so horribly awry, but I'm just not seeing it. From the paper: The first family of attacks, termed synchronous attacks, is applicable in scenarios where the plaintext or ciphertext is known and the attacker can operate synchronously with the encryption on the same processor, by using (or eavesdropping upon) some interface that triggers encryption under an unknown key. For example, a Virtual Private Network may allow an unprivileged user to send data packets through a secure channel. This lets the user trigger encryption of plaintexts that are mostly known (up to some uncertainties in the packet headers), and our attack would thus, under some circumstances, enable any such user to discover the key used by the VPN to protect all users’ packets. As another example, consider the Linux dm-crypt and cryptoloop services. These allow the administrator to create a virtual device which provides encrypted storage into an underlying physical device, and typically a normal filesystem is mounted on top of the virtual device. If a user has write permissions to any file on that filesystem, he can use it to trigger encryptions of known plaintext, and using our attack he is subsequently able to discover the encryption key used for the underlying device. We have experimentally demonstrated the latter attack, and showed it to reliably extract the full AES key using about 65ms of measurements (involving just 800 write operations) followed by 3 seconds of analysis. Questions: 1) In that example, the attacker "discovered the key used by the VPN to protect all users' packets." Does that mean the VPN reused the same AES key for each encryption? 2) If so, then if the VPN were to change the encryption key each time it encrypted a packet, wouldn't that protect against this attack? The attacker had to be able to trigger 800 encryptions that all used the same encryption key, right? Or does "write operation" refer to something other than "the attacker triggered an encryption of some known plaintext"?

tptacek 13y ago
The problem Osvik and Tromer are pointing out isn't that the VPN doesn't rekey; it's that the AES implementation it uses can't prevent a localhost attacker from learning its secrets by watching the footprints it leaves in the cache. There is no reasonable solution to that problem that doesn't involve eliminating the side channel. The problem isn't the key management; it's the broken AES deployment.
- sillysaurus2 13y ago
  What I think you're saying is, "the paper's point is that side channel attacks can be used to determine the key." I understand that... that's the whole point of the paper, after all. But wouldn't rekeying defend against this attack? And therefore how is what I originally said wrong (and hence how is it safe practice to reuse AES keys in general)? (I'm only trying to understand this.)
  - ghshephard 13y ago
    If you have a side channel attack then a single use of the key would be sufficient to break it-even a OTP would be vulnerable.
    - sillysaurus2 13y ago
      Then what does "800 write operations" refer to, if not 800 encryptions? How can a side channel be used to break a single encryption? Also, how would a one time pad be vulnerable to any side channel attack? That seems like it makes no sense. What am I missing here?
      - ghshephard 13y ago
        http://en.wikipedia.org/wiki/Side_channel_attack http://en.wikipedia.org/wiki/Side_channel_attack does a really good job Of describing it, but, in short, a side channel attack isn't a weakness in the algorithm - both a OTP and AES are strong. Rather, the side channel attack describes information leaked in a particular implementation. If your OTP implementation left some registers or cache lines in a state from which key information could be gleaned, then the attacker would be able to decrypt your message. Side channel attacks are about weaknesses in implementations, not algorithms.
        sillysaurus2 13y ago
        Yes, but it makes no sense that a one time pad would leak key information via cache timing, because the entire operation is just 'message xor key'." With a one time pad, the key's length has to be the length of the plaintext. There's no way for the key to be leaked through cache timing, because no memory location is ever read twice. The entire operation is simply: read a byte of plaintext; read a byte of key; XOR the two, writing the resulting byte" It makes no sense to use cache timing attacks against one time pads, because the speed of memory access is independent of the key and plaintext! If you have a side channel attack then a single use of the key would be sufficient to break it-even a OTP would be vulnerable. Let me try to put it another way: as far as I know, there are no reasonable side channel attacks against one time pad encryption, and certainly no cache timing attacks. So I don't understand why you're saying OTP is vulnerable to side channel attacks. Also, how is it possible for a single use of the key to be vulnerable to a timing-based side channel attack? If I'm wrong, please point out precisely what I've said that's wrong, so that I can learn from my mistake. I'll reword my original questions for clarity: does "800 write operations" mean "the attacker initiated 800 separate encryption operations, each using the same encryption key X, then analyzed the cache timing in order to infer X"? If so, doesn't that mean this attack can be defended against by changing the AES key for each encryption operation? And if that's correct, then by definition isn't it less safe (if not unsafe) to reuse your AES key?

tptacek 13y ago
There was a paper just published that built on Osvik & Tromer that recovered a GPG RSA key from a single run of GPG. This problem has nothing to do with key reuse.
- sillysaurus2 13y ago
  I think this is the paper you're referring to: http://eprint.iacr.org/2013/448.pdf http://eprint.iacr.org/2013/448.pdf The only reason they were able to recover the key in a single run is because GPG uses branching in its inner loop, making it trivial to determine the difference in timing between 1 and 0 bits of the key. AES requires no such branching. Attacking AES requires that the attacker try to predict the key, then calculate how long encryption would take if the attacker's guess was correct, then compare that guess to how long it actually took. This means it's not possible to recover the AES key in a single run unless the attacker happened to guess it correctly the first time (which is effectively impossible). In other words, the paper you cited apparently doesn't build off of Osvik & Tromer at all, except in the sense that they're both cache timing attacks. The paper uses a completely different technique than Osvik & Tromer. So how is it safe to reuse your AES key? I'm just trying to understand. Since the attacker needs multiple runs to attack AES, then wouldn't the logical defense be to rekey after every encryption? It seems like you've been saying "it's impossible to defend against a side channel attack." But that doesn't seem to be true in the case of AES, as long as you don't reuse your key. What am I missing?
  - tptacek 13y ago
    No, that's not what I'm saying. I'm saying that the solution to side channel attacks is to eliminate the side channel, not to redesign the cryptosystem around it. I keep telling you this: you can reuse AES keys. Reusing an AES key does not in any intrinsic way reduce the security of AES (at least, not unless you encrypt a truly staggering amount of data with it). However: you should not be working with encryption at this level of detail anyways. Sillysaurus 2, please go download Nacl and play with it. You'll be using 2012 crypto instead of debating implementation flaws in old crypto.
    - sillysaurus2 13y ago
      Okay, I was finally able to find a direct answer to my question by studying NaCl. http://cryptojedi.org/peter/data/tenerife-20130121.pdf http://cryptojedi.org/peter/data/tenerife-20130121.pdf "NaCl systematically avoids all loads from addresses that depend on secret data" "NaCl systematically avoids all branch conditions that depend on secret data" So NaCl is an implementation of AES encryption that prevents cache timing attacks. Since there are no other reasonable side channel attacks on AES, the AES key remains secure. Therefore reusing your AES key is ok provided you're using NaCl. (So you should probably be telling people they need to be using NaCl, not merely AES.) Thank you for the answers. Also, thanks for pointing me at NaCl. That's the most exciting crypto slide deck that's ever been written!