[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.