4 ms·
You can't. Or, well, you can, but it's redundant. One-time pads make sense in the Cold War, Vernam Square era of cryptography. But now that we have the internet
by dsacco 9y ago
You can't. Or, well, you can, but it's redundant. One-time pads make sense in the Cold War, Vernam Square era of cryptography. But now that we have the internet and public key cryptography, a one-time pad implemented in Ethereum would be inane and frivolous.
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.
- InclinedPlane 9y agoMy question was more: how do you ensure a system that has true secrecy for its one time pad data when all the source is open?
- PeterisP 9y agoThe code will inevitably need to use a source of true randomness, which will be external to your source code, by definition it can't be a deterministic formula, it needs to use external input from physical devices.
- InclinedPlane 9y agoAnd? You've just moved the problem, you haven't solved it. How do you guarantee that your source is what you think it is? If you can't trust anything outside your source code, then you can't trust anything outside your source code. 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.
- PeterisP 9y agoI'm not moving the problem, I'm stating that the problem (as it seems you're stating it) is unsolvable, you simply cannot have a closed crypto system where looking at the source is sufficient to ensure that it's secure. 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.