Yes. One time pads are unbreakable.

"Even after the aliens from Andromeda land with their massive spaceships and undreamed-of computing power, they will not be able to read the Soviet spy messages encrypted with one-time pads (unless they can also go back in time and get the one-time pads)." (Bruce Schneier, Applied Cryptography)

- Vernor Vinge, "A Fire upon the Deep"

Yes, it's well known that two-time pads are very vulnerable in ways that one time pads are not.

Even if the cryptography is sound, you also need to ensure that no user error can happen.

"Dirty" is one way to put it, yes. I'd personally use something like "false god" or "blasphemy" :). "Unbreakable" is a naive way of describing cryptographic algorithms, because it preempts conversations about intractability assertions or complexity analysis...modern cryptography accepts as a premise that "unbreakable" is not a reasonable goal, which is why we work by quantifying computational cost.

When I see someone use the phrase, "unbreakable cryptography", I mentally discount their authority to speak about cryptography and become more skeptical (this also applies to people who write things like "bank-grade security" or who tell me "AES-256" when I ask them how they're encrypting data, as if the key size is more important than the block cipher mode or confidentiality/authentication construction).

> Is there really such a thing as "unbreakable cryptography"?

A one-time pad, with the following provisos:

1. It has a truly random seed, not a pseudorandom one;

2. It is at least as long as the plaintext;

3. It is never reused (for the same plaintext, in whole or part).

It's straightforward to see why this guarantees information-theoretic security - you have no way of knowing when you've recovered the correct plaintext. There's nothing to brute-force.

In the security community we don't use one-time pads because we dare not touch the sun: they are extremely difficult to implement correctly, and even if you do implement them correctly you have traded off an inordinate amount of practical usability for a relatively small improvement in information theoretic security.

Asking people to 1) use true randomness to seed keys, 2) generate a new secret key for every message, 3) never reuse the same secret key and 4) keep each secret key securely confidential is extremely prone to error. It's often a fetishized ideal among people who first read about it, but in practice it's just not worth it.

One time pad systems are used regularly for high-security embassy-to-State Department communications. Since there are also secure couriers between those locations, there's a way to distribute key material. With today's storage densities, carrying key material around is easy.

Well that seems a bit pedantic, but yes, you're right. The difficulty I was focusing on however is the randomness itself, not how far it has to be extended. Ostensibly once you've incorporated a non-deterministic seed (which is necessarily external) into your process, you can extend it to the pad itself. The pad itself will just be a stream of that data, like a non-deterministic stream cipher. I get the impression you're aware of this already though, so I won't belabor it.

> One time pad systems are used regularly for high-security embassy-to-State Department communications. Since there are also secure couriers between those locations, there's a way to distribute key material. With today's storage densities, carrying key material around is easy.

Fair enough, I'll concede they have practical uses in situations where there are couriers and extremely high security requirements. That's about all they're practical for, though :)

I might be just misunderstanding you though.

So no, you're not misunderstanding - I just communicated poorly!

Is it just the fact that it would take two trips for the courier? Or that someone would need to intercept both communications (pad, ciphertext)?

The internet is an untrusted medium, since packet switching requires packets to travel through routers that can edit them at will. (The fabled man in the middle attack) This is the whole point of the certificate issuer public-key infrastructure, where issuer public keys are included in your OS's installation files, a secure communication channel. (If you can't trust your OS, you of course can't trust any communication made with it to be secure anyway)

How do you guarantee the third condition? Wouldn't you eventually run into the birthday problem if you sent enough messages?

Yes! And this is what's critical to the success of the one-time pad: you've not just encrypted data, you've encrypted data in such a fashion that (from the attacker's perspective), all plaintexts they recover are equally likely. Cryptanalysis is fundamentally impossible.

The information theory is absolutely groovy, but the application of it is unfortunately impractical.

Not that it matters. The sqrt(n) birthday effect isn't sufficient to overcome the exponentially low chance of a one-time pad collision for pads of any substantial size.

And to expand on this - this is why it is imperative that a source of true randomness is used as a seed. Pseudorandomness cannot (by definition) satisfy statistical independence.

If you don't have a source of true randomness, you've just implemented a stream cipher, not a one-time pad.

You're not likely to get a collision ever because of the typical sizes of one-time pads - birthday paradox matters if the key length is measured in bytes, but not if it's measured in gigabytes, there isn't enough space/time in our universe to expect a collision.

Well if it's that important maybe they should put that right in the name...

Take Alice and Bob, who want to communicate confidentially. Alice doesn't know Bob personally, so she can't securely communicate the one-time pad to Bob in person. Ethereum implements public-key cryptography, so she uses Bob's public key to send him the one-time pad's key. But now we're at the chicken and egg problem: we've just witnessed secure communication, so why do we want to use a one-time pad in the first place?

Alice and Bob might respond, "so we can have perfect secrecy at some point in the future!" Which...alright, sure, let's go with it. So now to implement the one-time pad in Ethereum, Alice needs to feed a source of true randomness as a seed for a secret key which is as long as the plaintext. This is not only a genuinely hard problem, but it's grossly inefficient to encrypt something using a secret key as long as the plaintext itself. But wait - for every new plaintext, Alice has to do this true random seed song and dance each time to generate a new secret key. And every secret key ever used needs to be kept perfectly secret as well.

You really just don't want to do this. One-time pads barely made sense in pre-modern cryptography; they don't solve any practical problems in modern cryptography, and their demands require steep usability sacrifices that are quite easy to screw up.

If you can't trust, say, a url or an IP address. Then you can't trust those things to host a source of randomness either. Security is only as strong as the weakest link, if you try to obfuscate a weak-link by surrounding it with impressive looking junk, that doesn't make it stronger.

You need an external source of entropy to generate the key material required for any cryptography. It can't be in your code because any code is fundamentally incapable of doing that. If your source of entropy is compromised, then none of cryptographic systems are safe, not symmetric, not asymmetric, not one-time pads, not anything else.

Yes, you can't trust an url or an IP address - but you should be able to trust your hardware, and that commonly offers some decent sources of entropy. You can also trust yourself - e.g. user-action derived entropy. If you don't trust your hardware, tough luck, get trusted hardware. If your key material isn't generated properly, then your crypto will not be secure.

It doesn't mean that the method is flawed or insecure. All methods are the same in this regard, it simply means that security requires not only secure code, but also other precautions - e.g. secure generation of keys, secure management/storage of keys, secure platform on which to run your code, etc, etc. If you have a secure algorithm, proper implementation, best practices everywhere else, then your system will still be insecure if you fail e.g. to store your keys securely and someone gets them.