3 ms·

And? 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 yo

And? 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 ago
I'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.

PeterisP 9y ago

I'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.