How to Conceal/Detect PGP Symmetric Algorithm Used

Question

When Symmetrically encrypting a file, (not signing, not an asymmetric encryption question), is it possible to conceal the encryption algorithm used, or is it already concealed, but just showing on systems as a result of being cached somehow?

Analogy: When signing an encrypted file, it is possible to conceal the recipient ID. But how do you conceal the encryption algorithm used when using Symmetrical encryption using GnuPG, (gpg4win, in this case)?

Example:
gpg --armor --symmetric --cipher-algo AES256 --output encryptedOutputFile.asc unencryptedInputFile.txt

and then:
gpg --decrypt plaintextfile.txt

yields:
gpg: AES256 Encrypted Data
gpg: encrypted with 1 passphrase

Observation:

Somehow, gpg4win is using Space Magic to infer what the symmetric algorithm is even before the passphrase is entered. How is this occurring? I tried to eliminate the possibility of the algorithm being present in the cache, but it still is being inferred. GPG uses CAST5 by default, so how is it inferring AES256?

So, how is GPG inferring that AES256 is used, even before the passphrase is specified?

Is there any way to conceal the algorithm used with a gpg -- flag?

Thank you!

Answer 1

Note, there is no legitimate reason to hide the algorithm used if you use a suitably strong passphrase/key.

If you are really concerned, you could open the encrypted file in a hex editor and change the fourth byte of the symmetrically encrypted ASCII armored file.

E.g., the first four bytes of an symmetric encrypted file are:

8C 0D 04 09

with the fourth byte being 09 indicating AES256. See common/openpgpdefs.h to see other values:

typedef enum
  {
    CIPHER_ALGO_NONE        =  0,
    CIPHER_ALGO_IDEA        =  1,
    CIPHER_ALGO_3DES        =  2,
    CIPHER_ALGO_CAST5       =  3,
    CIPHER_ALGO_BLOWFISH    =  4, /* 128 bit */
    /* 5 & 6 are reserved */
    CIPHER_ALGO_AES         =  7,
    CIPHER_ALGO_AES192      =  8,
    CIPHER_ALGO_AES256      =  9,
    CIPHER_ALGO_TWOFISH     = 10, /* 256 bit */
    CIPHER_ALGO_CAMELLIA128 = 11,
    CIPHER_ALGO_CAMELLIA192 = 12,
    CIPHER_ALGO_CAMELLIA256 = 13
  }
cipher_algo_t;

So if you change the byte to 0a (decimal 10), it will think I used twofish rather than aes256. It will not be possible to decrypt with gpg until I change the byte back to 09.

Before altering I see:

$ gpg -d some_file.gpg 
gpg: AES256 encrypted data
Enter passphrase: 

and after altering that byte I see:

$ gpg -d some_file.gpg 
gpg: TWOFISH encrypted data
Enter passphrase: 

Granted this only adds obscurity and forces you to remember to change the byte back and greatly lowers readability. I do not suggest you do this.

Answer 2

It looks like the passphrase which was used to encrypt the message with is encrypted with AES256. The algorithm used to encrypt the message is self is not known until the encrypted session key packet is decrypted.

This is what pgpdump shows:

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - AES with 256-bit key(sym 9)
Iterated and salted string-to-key(s2k 3):
    Hash alg - SHA1(hash 2)
    Salt - f8 8d cc 5f 67 70 ee 2a 
    Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(294 bytes)
Ver 1
Encrypted data [sym alg is specified in sym-key encrypted session key]
    (plain text + MDC SHA1(20 bytes))

The Symmetric-Key Encrypted Session Key Packet contains "A one-octet number describing the symmetric algorithm used" (see RFC 4880). It seems that the algorithm with which the session key is encrypted with is required (unless you want to break the RFC)

It looks like you cannot suppress adding the algorithm used for the encryption of the passphrase.