9 ms·

Be wary of one-time pads and other crypto unicorns

73 points by randomwalker 12y ago

some_furry 12y ago
> RC4 is almost 30 years old now, and despite it being “broken” practical attacks still require enormous amounts of ciphertext and would probably not affect security in a meaningful way if you deployed it in a messaging app. Sure, but please use ChaCha20-Poly1305 if you can. Two libraries (nacl and libsodium) implement it for you; libsodium is a portable implementation of nacl with bindings for most popular programming languages.
- tptacek 12y ago
  Sodium/Nacl is a good recommendation. If you can use them, do. If you're not using Sodium/Nacl, don't go out of your way to use Salsa/ChaCha/Poly1305. If your platform has a good AES-GCM, that's also fine. The important thing is to use the best tested, simplest interface available to you. If switching from AES to ChaCha means you have to do any of your own protocol design, it's not a win.
  - some_furry 12y ago
    > If you're not using Sodium/Nacl, don't go out of your way to use Salsa/ChaCha/Poly1305. Right, sorry if I implied that anyone should roll their own crypto libraries. Use the standard implementations! http://doc.libsodium.org/bindings_for_other_languages/README.html http://doc.libsodium.org/bindings_for_other_languages/README... For PHP developers: https://github.com/defuse/php-encryption https://github.com/defuse/php-encryption (wrapper for openssl)
peterwwillis 12y ago
"We don’t need crypto unicorns so much as we need diligent engineering to deploy the crypto we already have." If we took this seriously, we would all still be using modified versions of DES, which, in a twisted way, we are. This isn't a good argument for ignoring new implementations of different cryptosystems. "If a new crypto tool is first announced in a press release or popular science magazine, don’t use it." This is far more accurate, but i'd extend this even further and define it as: "Don't use any new crypto." (Unless it comes from someone with high social influence in the sphere of cryptography research, of course)
- kedean 12y ago
  I don't think DES is an accurate comparison here. The world abandoned DES because a) everyone suspected it had a backdoor, and b) it was demonstrably broken by the EFF in 1999. We rely on a primitive until someone who's job it is finds holes in it. Engineers don't need to be inventing new encyrption.
  - tptacek 12y ago
    DES was abandoned because its key size was too small. It also has a block size that's too small for safety, which is why we don't use Triple DES or Blowfish as bulk ciphers either. Ever since Biham and Shamir published the differential cryptanalysis, we've known that NSA didn't backdoor DES, but rather helped strengthen it against that attack. Concerns over a backdoor had nothing to do with it.
cbd1984 12y ago
"Uses, or claims to use, one-time pads" is, by itself, strong enough evidence that an encryption product is bogus that you'd be wise to not use the product based on that evidence alone. Similar is the claim that it uses a proprietary algorithm. https://www.schneier.com/crypto-gram/archives/1999/0215.html https://www.schneier.com/crypto-gram/archives/1999/0215.html
hurin 12y ago
There are old established methods to guarantee sufficient security for message encryption, it's rather trivial and idk why every other new product has to reinvent the wheel. Key Exchange on the other-hand is hard and much more likely to be the failure point.
DanielBMarkham 12y ago
I'm not a crypto expert, but I understand the terms and arguments made in this article. "Wary" is the key word. If I have a true physical RNG, I can certainly make 2 DVDs full of identical random numbers. I can share one with you -- physically, not using email or barcodes. We can then communicate in the open, saying something like "beginning at position x on the DVD, here is my message" and nobody can read the part of the message that travels between the crypto functions They can still read my keystrokes, or gain entrance to where I work and video record me. They can gain useful information simply based on the pattern of you and I communicating. They even may be able to surreptitiously copy our OTP by using compromised software. But the OTP part is secure. The real problem is that the entire OSI stack is a leaking piece of crap. It's been broken at every level. So even if you have "perfect" crypto? It doesn't matter so much. ADD: Nothing's stopping you from using a OTP on top of a normal set of crypto algorithms. I like the OTP idea -- I'm just not sure in the current environment you're getting anything from it.
- spacemanmatt 12y ago
  I like your pragmatic way of analyzing this issue, and I think we have far more security work to do in operations than in algorithms.
- vog 12y ago
  > They can still read my keystrokes [...] They even may be able to surreptitiously copy our OTP by using compromised software. > The real problem is that the entire OSI stack is a leaking piece of crap. How is breaking into your computer an issue of the OSI stack? Are you using "OSI stack" as synonymous to "the whole operating system with all its running processes"?
  - DanielBMarkham 12y ago
    Yes, I was, but more specifically I was giving two examples of the types of insecurities found in modern technology. It was a broad argument and a loose choice of examples. Thanks for pointing that out. The point was that "don't try this at home" is a little over-used from experts. Even novices can poke holes in the idea here -- so perhaps my loose argument was appropriate.
josephg 12y ago
So, there's a pattern I'm noticing again and again. Whenever a startup announces a new secure communication product, extremely knowledgeable and respected people in our community write posts talking about the (awful) mistakes they've made. In the wake of the Snowden revelations, its incredibly important that we bootstrap a usable new generation of software with security at its core. But I'm worried that lots of people will be afraid to make security a core feature of their product because of the bad press they'll get if they do it a little bit wrong. Frankly the security community does not have a history of making systems that my mum can use. We really need an army of software engineers to work on fixing this problem and I don't think blog posts like this are helping. (Notable exception is Textsecure). In this case, as I understood the press release: - The QR code is used to initialize a direct (encrypted) bluetooth / wifi direct connection. Taking a picture of the QR code isn't enough to get the one-time pad. - Cameras on modern mobile phones should be able to generate more than enough entropy (even if this isn't happening yet). But there is no discussion of these points so far. Everybody is just piling hate on the product for its failings. We need to be better than that if we want a secure app ecosystem.
- Nursie 12y ago
  >> The QR code is used to initialize a direct (encrypted) bluetooth / wifi direct connection. Taking a picture of the QR code isn't enough to get the one-time pad. If, as the article says, the QR code gives a symmetric AES key, then yes it could well be enough to get the OTP if you've eavesdropped on the traffic as well. >> But there is no discussion of these points so far. Everybody is just piling hate on the product for its failings. We need to be better than that if we want a secure app ecosystem. What we need to be better at is recognising that "Hey, look at my brand-new awesome crypto-system!" is a huge red flag, and what we should be looking for is "Hey, we're using tried and tested protocol X, which we're pretty confident about". From an app-writer's perspective I can see why they want to announce that they've made this awesome new security system - they want to differentiate themselves, and security is in the public eye right now so seems to be a selling point. Human nature being what it is, new and shiny is eye-catching and good for sales. But we really want pretty much the opposite here.
- maxerickson 12y ago
JacobEdelman 12y ago
The sad thing is that really cool, potentially world changing, crypto has been created in the past few years but its not the crypto that gets media coverage. Concepts like Fully Homomorphic Encryption and Secure Obfuscation may revolutionize security in the coming years, but nobody has heard of them precisely because they were published in scholarly journals instead of popular science magazines. Maybe cryptographers should create useless apps that claim to solve all security problems whenever they come up with actually important crypto :)
- jfindley 12y ago
  Well. Homomorphic encryption is still very much an emerging tech. For most applications it's still too slow. There's all sorts of cool things we can build when it gets a bit more mature, but for now it's not unreasonable that there's no press coverage of it. On secure obfuscation - there was actually a wired article about this (unsurprisingly the title was rather overhyped and click-baity), so I don't think it's fair to say it didn't get press coverage. This is closer to being usable in the real world and thus got more press coverage. Again though, it seems unfair to complain about the amount of coverage it got, because regular readership can't go out and use it yet. The problem IMO is more that there's a conflict between the big splashy software release that gets you lots of users and attention, and the slow careful discussions on crypto lists that gets you more confidence your software is actually secure before it's in the hands of end users. Without the big release, it can be hard to build a user-base - and if no-one uses your new more-secure messaging app it doesn't really do a lot of good. Without the slow discussions you're potentially endangering your users. Some sort of compromise is probably the answer, but I'm not sure exactly what that should look like (although I have some ideas).
utnick 12y ago
I have a few comments/questions about the post: 1) Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? What extra weaknesses do one time pads expose? 2) For their 2nd point, Zendo has said that the pad exchange happens locally ( device to device ). So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. 3) Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... if sha256 is broken, a man in the middle would be able to corrupt messages, but not in a meaningful way ( ie switching yes to no ), it would just look like garbage to the other person... I think #1 is probably the biggest issue, I'd like to understand it a bit more.
- deleted 12y ago
  [deleted]
- Nursie 12y ago
  >> Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? It amounts to basically the same thing. That's the point there, what's happening in the phone is a small amount of random data is being used to generate a large amount of pseudo-random data. The security of the OTP is therefore dependent upon the PRNG and in effect you are using the PRNG as your stream-cipher. It doesn't buy you anything. >> So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. With other schemes that use similar things, the exchange is of public keys. Zendo appears to use the barcode as a symmetric key, meaning that the transfer can be eavesdropped/intercepted/impersonated a bit more easily. In an asymmetric situation you could encrypt all messages with the receiver's public key and ensure only they can decrypt. >> Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... This is more of a criticism of style, and how little they have disclosed.
- falcolas 12y ago
  Encryption keys don't need to be as long as one time pads. One time pads need to be large enough to encompass the size of all communications which are encrypted by them. Encryption keys need to be a couple k in size at most. For 2 and 3, basically the author is stating that the use of a one time pad is redundant at best, and potentially crippling at worst (since the capture of a copy of the OTP compromises all communications, backwards and forwards, and it would be tempting to re-use the OTP instead of constantly having to meet back up and generate a new one).
tptacek 12y ago
Another way to say this: there's a hierarchy of ways in which cryptography fails. At the very lowest level, a cipher can catastrophically fail, like FEAL-4 did. Going up through the levels, your block cipher mode (the adapter layer that allows a fixed-size cipher to encrypt a whole message) could be improperly constructed. Your random number generator could be biased. Your messages could be unauthenticated. You can accidentally create an oracle from observable behavior. Your key exchange could be insecure. Your UX could be insecure, so it's impossible to tell who you're talking to. Your encryption could be off by default. Of all the levels where modern cryptosystems are going to fail, a catastrophic failure of the cipher itself is the least likely. It is fantastically unlikely that a secure messaging app is going to fall because AES is broken. And the best fundamental attacks on the worst ciphers still make demands of attackers that are unrealistic for message apps. So the whole idea of using a one time pad to secure a messaging app is alarming. It's like an engineer told you they were going to design a bridge out of, I don't know, lithium to save on weight. There are lots of ways for a cryptosystem to fail. Unlike fundamental cipher breaks, which are so extraordinarily rare as to be discountable, some of them are very, very likely. In cryptography engineering, the way these problems are mitigated is to use standardized, well-known, well-tested constructions. Any time you leave the golden path --- an AEAD stream cipher construction --- you're risking lots of flaws across every layer of your cryptosystem. Doing that to avoid an AES break is malpractice. Also, as this post points out: this app didn't even use an OTP. It used a stream cipher keyed by the HMAC-DRBG (iirc) embedded in JVM SecureRandom. So there's that, too.
- samatman 12y ago
  Serious question: does the same apply to encryption between routers? Like large PiB/day loads. Between the old 'bandwidth of a 747 full of tapes' exercise and the speed of XOR, I've wondered for awhile now why it isn't standard. Specialized entropy sources can make a lot of the stuff rapidly, and it seems like a case where reducing that layer of security to a a couple consumable tapes that get swapped out like batteries when they're dead would be practical, and would have the advantage that seizing the cipher clearly involves having several tens of grammes of tightly-encoded data.
  - 12y ago
wodenokoto 12y ago
So in order to start breaking Zendo, you need to break AES-256 and SHA-256?
pdkl95 12y ago
Usually, the complaint with OTP is how to move a copy of the pad in a way that is both secure and still useful/practical. I think there is a simple solution to this (at least some of the time) if you limit the scope to "friends that meet occasionally". What I want to make[1] is a pair of basically any embedded micro, in a "thumbdrive-ish" (or whatever for the prototype) size that has some amount of flash on it to store the pad, a USB interface, and a hardware-RNG[2]. Additionally, there is some sort of serial interface that will be used to null-modem two of these devices together. When connected, the devices generate public keys (for authentication, etc), and generate noise. They send the noise to each other, and save the XOR of the noise to flash, so no device has total control of the generation. The idea is that the "user experience" would be this: go over to a friends house, and plug your devices together for some period of time (hours, probably, but it can be cut off early). Then when you go home, plug it in to your computer and you can chat securely, slowly burning the pad from flash automatically. This is done over USB, so the pad never leaves the device. The firmware can handle the destruction of the pad as it is used and other details. This doesn't solve everything, and the pad would run out fast if you wanted to send non-text data. What it should do is make it trivial for two parties to chat/email securely. Details like refilling the pad (visit friend for dinner, plug devices together while you eat) shouldn't be hard for most people, as long as they can see how much pad is remaining. [1] I plan to implement a prototype of this as soon as I have spare time & cash for some hardware to experiment on. [2] probably using something like the reverse-biased transistor method discussed in TFC

73 points by randomwalker 12y ago

> RC4 is almost 30 years old now, and despite it being “broken” practical attacks still require enormous amounts of ciphertext and would probably not affect security in a meaningful way if you deployed it in a messaging app. Sure, but please use ChaCha20-Poly1305 if you can. Two libraries (nacl and libsodium) implement it for you; libsodium is a portable implementation of nacl with bindings for most popular programming languages.

tptacek 12y ago
Sodium/Nacl is a good recommendation. If you can use them, do. If you're not using Sodium/Nacl, don't go out of your way to use Salsa/ChaCha/Poly1305. If your platform has a good AES-GCM, that's also fine. The important thing is to use the best tested, simplest interface available to you. If switching from AES to ChaCha means you have to do any of your own protocol design, it's not a win.
- some_furry 12y ago
  > If you're not using Sodium/Nacl, don't go out of your way to use Salsa/ChaCha/Poly1305. Right, sorry if I implied that anyone should roll their own crypto libraries. Use the standard implementations! http://doc.libsodium.org/bindings_for_other_languages/README.html http://doc.libsodium.org/bindings_for_other_languages/README... For PHP developers: https://github.com/defuse/php-encryption https://github.com/defuse/php-encryption (wrapper for openssl)

peterwwillis 12y ago

"We don’t need crypto unicorns so much as we need diligent engineering to deploy the crypto we already have." If we took this seriously, we would all still be using modified versions of DES, which, in a twisted way, we are. This isn't a good argument for ignoring new implementations of different cryptosystems. "If a new crypto tool is first announced in a press release or popular science magazine, don’t use it." This is far more accurate, but i'd extend this even further and define it as: "Don't use any new crypto." (Unless it comes from someone with high social influence in the sphere of cryptography research, of course)

kedean 12y ago
I don't think DES is an accurate comparison here. The world abandoned DES because a) everyone suspected it had a backdoor, and b) it was demonstrably broken by the EFF in 1999. We rely on a primitive until someone who's job it is finds holes in it. Engineers don't need to be inventing new encyrption.
- tptacek 12y ago
  DES was abandoned because its key size was too small. It also has a block size that's too small for safety, which is why we don't use Triple DES or Blowfish as bulk ciphers either. Ever since Biham and Shamir published the differential cryptanalysis, we've known that NSA didn't backdoor DES, but rather helped strengthen it against that attack. Concerns over a backdoor had nothing to do with it.

cbd1984 12y ago

"Uses, or claims to use, one-time pads" is, by itself, strong enough evidence that an encryption product is bogus that you'd be wise to not use the product based on that evidence alone. Similar is the claim that it uses a proprietary algorithm. https://www.schneier.com/crypto-gram/archives/1999/0215.html https://www.schneier.com/crypto-gram/archives/1999/0215.html

hurin 12y ago

There are old established methods to guarantee sufficient security for message encryption, it's rather trivial and idk why every other new product has to reinvent the wheel. Key Exchange on the other-hand is hard and much more likely to be the failure point.

DanielBMarkham 12y ago

I'm not a crypto expert, but I understand the terms and arguments made in this article. "Wary" is the key word. If I have a true physical RNG, I can certainly make 2 DVDs full of identical random numbers. I can share one with you -- physically, not using email or barcodes. We can then communicate in the open, saying something like "beginning at position x on the DVD, here is my message" and nobody can read the part of the message that travels between the crypto functions They can still read my keystrokes, or gain entrance to where I work and video record me. They can gain useful information simply based on the pattern of you and I communicating. They even may be able to surreptitiously copy our OTP by using compromised software. But the OTP part is secure. The real problem is that the entire OSI stack is a leaking piece of crap. It's been broken at every level. So even if you have "perfect" crypto? It doesn't matter so much. ADD: Nothing's stopping you from using a OTP on top of a normal set of crypto algorithms. I like the OTP idea -- I'm just not sure in the current environment you're getting anything from it.

spacemanmatt 12y ago
I like your pragmatic way of analyzing this issue, and I think we have far more security work to do in operations than in algorithms.
vog 12y ago
> They can still read my keystrokes [...] They even may be able to surreptitiously copy our OTP by using compromised software. > The real problem is that the entire OSI stack is a leaking piece of crap. How is breaking into your computer an issue of the OSI stack? Are you using "OSI stack" as synonymous to "the whole operating system with all its running processes"?
- DanielBMarkham 12y ago
  Yes, I was, but more specifically I was giving two examples of the types of insecurities found in modern technology. It was a broad argument and a loose choice of examples. Thanks for pointing that out. The point was that "don't try this at home" is a little over-used from experts. Even novices can poke holes in the idea here -- so perhaps my loose argument was appropriate.

josephg 12y ago

So, there's a pattern I'm noticing again and again. Whenever a startup announces a new secure communication product, extremely knowledgeable and respected people in our community write posts talking about the (awful) mistakes they've made. In the wake of the Snowden revelations, its incredibly important that we bootstrap a usable new generation of software with security at its core. But I'm worried that lots of people will be afraid to make security a core feature of their product because of the bad press they'll get if they do it a little bit wrong. Frankly the security community does not have a history of making systems that my mum can use. We really need an army of software engineers to work on fixing this problem and I don't think blog posts like this are helping. (Notable exception is Textsecure). In this case, as I understood the press release: - The QR code is used to initialize a direct (encrypted) bluetooth / wifi direct connection. Taking a picture of the QR code isn't enough to get the one-time pad. - Cameras on modern mobile phones should be able to generate more than enough entropy (even if this isn't happening yet). But there is no discussion of these points so far. Everybody is just piling hate on the product for its failings. We need to be better than that if we want a secure app ecosystem.

Nursie 12y ago
>> The QR code is used to initialize a direct (encrypted) bluetooth / wifi direct connection. Taking a picture of the QR code isn't enough to get the one-time pad. If, as the article says, the QR code gives a symmetric AES key, then yes it could well be enough to get the OTP if you've eavesdropped on the traffic as well. >> But there is no discussion of these points so far. Everybody is just piling hate on the product for its failings. We need to be better than that if we want a secure app ecosystem. What we need to be better at is recognising that "Hey, look at my brand-new awesome crypto-system!" is a huge red flag, and what we should be looking for is "Hey, we're using tried and tested protocol X, which we're pretty confident about". From an app-writer's perspective I can see why they want to announce that they've made this awesome new security system - they want to differentiate themselves, and security is in the public eye right now so seems to be a selling point. Human nature being what it is, new and shiny is eye-catching and good for sales. But we really want pretty much the opposite here.
maxerickson 12y ago

JacobEdelman 12y ago

The sad thing is that really cool, potentially world changing, crypto has been created in the past few years but its not the crypto that gets media coverage. Concepts like Fully Homomorphic Encryption and Secure Obfuscation may revolutionize security in the coming years, but nobody has heard of them precisely because they were published in scholarly journals instead of popular science magazines. Maybe cryptographers should create useless apps that claim to solve all security problems whenever they come up with actually important crypto :)

jfindley 12y ago
Well. Homomorphic encryption is still very much an emerging tech. For most applications it's still too slow. There's all sorts of cool things we can build when it gets a bit more mature, but for now it's not unreasonable that there's no press coverage of it. On secure obfuscation - there was actually a wired article about this (unsurprisingly the title was rather overhyped and click-baity), so I don't think it's fair to say it didn't get press coverage. This is closer to being usable in the real world and thus got more press coverage. Again though, it seems unfair to complain about the amount of coverage it got, because regular readership can't go out and use it yet. The problem IMO is more that there's a conflict between the big splashy software release that gets you lots of users and attention, and the slow careful discussions on crypto lists that gets you more confidence your software is actually secure before it's in the hands of end users. Without the big release, it can be hard to build a user-base - and if no-one uses your new more-secure messaging app it doesn't really do a lot of good. Without the slow discussions you're potentially endangering your users. Some sort of compromise is probably the answer, but I'm not sure exactly what that should look like (although I have some ideas).

utnick 12y ago

I have a few comments/questions about the post: 1) Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? What extra weaknesses do one time pads expose? 2) For their 2nd point, Zendo has said that the pad exchange happens locally ( device to device ). So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. 3) Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... if sha256 is broken, a man in the middle would be able to corrupt messages, but not in a meaningful way ( ie switching yes to no ), it would just look like garbage to the other person... I think #1 is probably the biggest issue, I'd like to understand it a bit more.

deleted 12y ago
[deleted]
Nursie 12y ago
>> Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? It amounts to basically the same thing. That's the point there, what's happening in the phone is a small amount of random data is being used to generate a large amount of pseudo-random data. The security of the OTP is therefore dependent upon the PRNG and in effect you are using the PRNG as your stream-cipher. It doesn't buy you anything. >> So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. With other schemes that use similar things, the exchange is of public keys. Zendo appears to use the barcode as a symmetric key, meaning that the transfer can be eavesdropped/intercepted/impersonated a bit more easily. In an asymmetric situation you could encrypt all messages with the receiver's public key and ensure only they can decrypt. >> Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... This is more of a criticism of style, and how little they have disclosed.
falcolas 12y ago
Encryption keys don't need to be as long as one time pads. One time pads need to be large enough to encompass the size of all communications which are encrypted by them. Encryption keys need to be a couple k in size at most. For 2 and 3, basically the author is stating that the use of a one time pad is redundant at best, and potentially crippling at worst (since the capture of a copy of the OTP compromises all communications, backwards and forwards, and it would be tempting to re-use the OTP instead of constantly having to meet back up and generate a new one).

tptacek 12y ago

Another way to say this: there's a hierarchy of ways in which cryptography fails. At the very lowest level, a cipher can catastrophically fail, like FEAL-4 did. Going up through the levels, your block cipher mode (the adapter layer that allows a fixed-size cipher to encrypt a whole message) could be improperly constructed. Your random number generator could be biased. Your messages could be unauthenticated. You can accidentally create an oracle from observable behavior. Your key exchange could be insecure. Your UX could be insecure, so it's impossible to tell who you're talking to. Your encryption could be off by default. Of all the levels where modern cryptosystems are going to fail, a catastrophic failure of the cipher itself is the least likely. It is fantastically unlikely that a secure messaging app is going to fall because AES is broken. And the best fundamental attacks on the worst ciphers still make demands of attackers that are unrealistic for message apps. So the whole idea of using a one time pad to secure a messaging app is alarming. It's like an engineer told you they were going to design a bridge out of, I don't know, lithium to save on weight. There are lots of ways for a cryptosystem to fail. Unlike fundamental cipher breaks, which are so extraordinarily rare as to be discountable, some of them are very, very likely. In cryptography engineering, the way these problems are mitigated is to use standardized, well-known, well-tested constructions. Any time you leave the golden path --- an AEAD stream cipher construction --- you're risking lots of flaws across every layer of your cryptosystem. Doing that to avoid an AES break is malpractice. Also, as this post points out: this app didn't even use an OTP. It used a stream cipher keyed by the HMAC-DRBG (iirc) embedded in JVM SecureRandom. So there's that, too.

samatman 12y ago
Serious question: does the same apply to encryption between routers? Like large PiB/day loads. Between the old 'bandwidth of a 747 full of tapes' exercise and the speed of XOR, I've wondered for awhile now why it isn't standard. Specialized entropy sources can make a lot of the stuff rapidly, and it seems like a case where reducing that layer of security to a a couple consumable tapes that get swapped out like batteries when they're dead would be practical, and would have the advantage that seizing the cipher clearly involves having several tens of grammes of tightly-encoded data.
- 12y ago

wodenokoto 12y ago

So in order to start breaking Zendo, you need to break AES-256 and SHA-256?

pdkl95 12y ago

Usually, the complaint with OTP is how to move a copy of the pad in a way that is both secure and still useful/practical. I think there is a simple solution to this (at least some of the time) if you limit the scope to "friends that meet occasionally". What I want to make[1] is a pair of basically any embedded micro, in a "thumbdrive-ish" (or whatever for the prototype) size that has some amount of flash on it to store the pad, a USB interface, and a hardware-RNG[2]. Additionally, there is some sort of serial interface that will be used to null-modem two of these devices together. When connected, the devices generate public keys (for authentication, etc), and generate noise. They send the noise to each other, and save the XOR of the noise to flash, so no device has total control of the generation. The idea is that the "user experience" would be this: go over to a friends house, and plug your devices together for some period of time (hours, probably, but it can be cut off early). Then when you go home, plug it in to your computer and you can chat securely, slowly burning the pad from flash automatically. This is done over USB, so the pad never leaves the device. The firmware can handle the destruction of the pad as it is used and other details. This doesn't solve everything, and the pad would run out fast if you wanted to send non-text data. What it should do is make it trivial for two parties to chat/email securely. Details like refilling the pad (visit friend for dinner, plug devices together while you eat) shouldn't be hard for most people, as long as they can see how much pad is remaining. [1] I plan to implement a prototype of this as soon as I have spare time & cash for some hardware to experiment on. [2] probably using something like the reverse-biased transistor method discussed in TFC