All symmetrically encrypted data looks the same, but almost all encrypted wire formats and encrypted file formats contain some header information. In particular, GPG / OpenPGP encrypted files will contain a header with the public key's hash. Any investigator with more than a day's experience would check the same device for keyrings and check if any of the public or private keys in the keyrings match any of the messages.
It takes a lot of effort to make all of the metadata also not have distinguishable patterns. See DJB's "Elligator" papers for all of the work that goes into designing elliptic curves for this purpose.
It's really a pain to have a full protocol that looks like white noise even if the attacker has millions of message exchanges to look at. I designed a protocol like that about 20 years ago, using the Station-to-Station protocol with the largest 4096-bit safe prime as the DH modulus. I couldn't use the semantically secure version of DH, because in that case, the first 4096 bits exchanged each way would always be a quadratic residue. The modulus needed to be just under a power of 256, so that even with billions of samples, it wouldn't be surprising that none of them were between the modulus and the maximum N-byte integer. For the individual messages within the stream, I needed to encrypt the message length headers, etc., etc. Even with this white noise-looking protocol, I'm pretty sure the pattern of packet sizes used by TCP to encapsulate the stream would give away the protocol being used. It just really increased the amount of analysis a filtering firewall would need, and increased the false positive rate of attempts to block the protocol. These days, TLS is so common and the pain caused by blindly dropping all TLS connections is so great, that you're probably best off either tunnelling your hidden protocol through TLS, or else making your protocol look like a TLS handshake with common parameters.
It takes a lot of effort to make all of the metadata also not have distinguishable patterns. See DJB's "Elligator" papers for all of the work that goes into designing elliptic curves for this purpose.
It's really a pain to have a full protocol that looks like white noise even if the attacker has millions of message exchanges to look at. I designed a protocol like that about 20 years ago, using the Station-to-Station protocol with the largest 4096-bit safe prime as the DH modulus. I couldn't use the semantically secure version of DH, because in that case, the first 4096 bits exchanged each way would always be a quadratic residue. The modulus needed to be just under a power of 256, so that even with billions of samples, it wouldn't be surprising that none of them were between the modulus and the maximum N-byte integer. For the individual messages within the stream, I needed to encrypt the message length headers, etc., etc. Even with this white noise-looking protocol, I'm pretty sure the pattern of packet sizes used by TCP to encapsulate the stream would give away the protocol being used. It just really increased the amount of analysis a filtering firewall would need, and increased the false positive rate of attempts to block the protocol. These days, TLS is so common and the pain caused by blindly dropping all TLS connections is so great, that you're probably best off either tunnelling your hidden protocol through TLS, or else making your protocol look like a TLS handshake with common parameters.