I think you're missing the implication in the original comment, that the NSA has put a backdoor into NIST and the Russian equivalent has put a backdoor into GOST, but neither can use the other's backdoor.
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.
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.
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.
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.