[tptacek]

I cannot tell you how silly this is. If you're using GOST, you're no longer building NIST-compliant crypto. If you're using NIST, you're no longer building GOST-compliant crypto. For Christ's sake, just stop using standardized crypto if you're worried about backdoors like this. Use an eSTREAM portfolio cipher for bulk crypto, use Blake2 as your hash, and use Curve448 for key agreement and signatures.

You can just use the Noise protocol framework to accomplish this, which was designed to use all of these components.

[hueving]

It's still NIST compliant crypto on the outside regardless of the inner contents. Assuming NIST(GOST(plaintext)), NIST would be terribly broken if using GOST ciphertext as the payload weakened the security.

It's crypto 101 that, given a ciphertext without the key, an algorithm's correct input should be indistinguishable from random input of the same length.

I'm shocked that you think the plaintext contents would have an affect on whether or not something is NIST compliant.

[tptacek]

I don't follow this objection even a little bit, but I'm also not very motivated to try, so: no need to clarify. I'm just going to reiterate.

I am making a very simple point. If you don't trust NIST standards because you think they're backdoored, but won't run Russian standards because you think they might be too, the answer isn't to compose the two flawed standards.

Instead: just use a crypto stack composed of well-reviewed, well-regarded components that are neither NIST nor GOST standards.

Nobody in the world thinks Curve25519 is backdoored, or that Chapoly is, or that Blake2 is.

In fact: this is what I think you should do anyways. Maybe, just maybe, you should keep using AES because it will be more performant --- but the cycles/byte cost of bulk encryption is so low that I'm skeptical that this matters. Otherwise: avoid crypto standards like NIST and GOST. Standards processes produce crypto that is at best ungainly and at worst actively harmful. Standards are evil.

I am, of course, addressing this advice to the very, very limited subset of engineers who should be working with crypto directly. Everyone else should just use Nacl.

[hueving]

If you think standard A is good except for a potential backdoor with the key held by entity X and you think standard B is good except for a potential backdoor held by entity Y and you assume entity X and entity Y do not cooperate, then composing A and B is completely reasonable.

It's the same thing as having 3 computers vote on the space shuttle control signals. You could follow your argument and claim, "If the software has a bug in it that would produce output different from the other 2, then don't use it!" The problem is that we don't know if there is an issue or not, so we go the safer route with multiple implementations.

You also did not address the main issue I have with your comment. You made this assertion: "If you're using GOST, you're no longer building NIST-compliant crypto.", which implies that the contents of the plaintext determine if the crypto is NIST compliant. This is completely false.

It's like claiming that uploading an AES encrypted file over an HTTPS connection is less secure than uploading via HTTP.

[tptacek]

Considering only the secure channel problem and not the entire systems problem (which might motivate encrypting clientside in anticipation of the file being stored), encrypting before sending on a secure channel is indeed pointless, which is the reason you'll find very few soundly designed cryptosystems that do this.

The point is again simple: there are far better options to untrustworthy standards than composing them in the hopes of mitigating their flaws. It's for the same reason that we used to use hash combiners to handle MD5 and SHA1, but now we use HKDF over SHA-2.

[hueving]

>which is the reason you'll find very few soundly designed cryptosystems that do this.

Nearly every secure system I've dealt with (in the military side) encrypted at the network layer (VPN) and they sent encrypted files over that channel.

[tptacek]

Yes, because (as I just said), encrypting files mitigates systems problems outside the scope of the secure channel problem. A secure channel doesn't help you if the bag of bits you send down it ends up persisted on an exported, unencrypted filesystem.

That doesn't mean that redundant clientside encryption of files is a sensible feature for a secure channel to have.