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)?

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

and then:
gpg --decrypt plaintextfile.txt

gpg: AES256 Encrypted Data
gpg: encrypted with 1 passphrase


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!

  • Just to clarify, entering your passphrase has nothing to do with the actual message decryption/encryption. For encryption it's for decrypting your private key file to sign the message. For decryption it's used to decrypt your private key file to decrypt the symmetric crypto data. I'm not entirely sure how the algorithm is known with GPG, but it's entirely possible that it gets encrypted with the session key. That way after decryption it has everything it needs to decrypt. – RoraΖ Aug 19 '14 at 19:01
  • Just to clarify, my question isn't about A-symmetric encryption, or signing messages. This is entirely about S-ymmetric Encryption ... Will clarify the question as well. – Wind And Flame Aug 19 '14 at 19:06

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 */

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.

  • Thank you! This is /exactly/ what I was looking for. Going to modify the source to prompt for algorithm when it sees 0x00, or 0xFF ... Thank you for humoring a not so intuitive question. – Wind And Flame Aug 19 '14 at 22:18
  • 1
    I just want to offer a "soft" correction. You said, "there is no legitimate reason to hide the algorithm used ..." In general, I think you are right. However ... there are some edge cases where obfuscation, misdirection, or concealing the use of a specific alogorithm not permitted by a certain policy could be necessary. But still, thank you for answering. It is usually the case that tech forum answers are littered with, "Why would want to do that??" In many cases, a little Creativity + Technology = LolZ .. All kinds of fun reasons. :) Thank you again. – Wind And Flame Aug 20 '14 at 1:50
  • @WindAndFlame This may turn out not to be fun. I'm very unsure that the fact you have to set encoding explicitly in this schema cannot be exploited in some way. Please, don't modify protocols for fun. – polkovnikov.ph Aug 29 '16 at 12:28
  • @polkovnikov.ph As long as they modify it correctly and don't e.g. change the wrong bytes, it should not be able to make it any easier to exploit than otherwise. Otherwise an attacker could just change it themselves in order to gain an advantage. – forest Feb 25 '18 at 8:12

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.

  • I copied the original encrypted files to new files, and renamed... It still autodetects the algorithm used. – Wind And Flame Aug 19 '14 at 20:05
  • 2
    That's because a Symmetric-Key Encrypted Session Key Packet contains "A one-octet number describing the symmetric algorithm used" (see tools.ietf.org/html/rfc4880#page-38). It seems that the algorithm with which the session key is encrypted with is required (unless you want to break the RFC) – martijnbrinkers Aug 19 '14 at 20:20
  • Thank you for the reference. tools.ietf.org/html/rfc4880#section-9.2 seems to specify exactly which algorithm is used. For the life of me, I don't understand why they don't have an "omitted" or otherwise /obfuscated/ reservation. :) But it appears we know how it is inferring the algorithm used, but I am not certain how to go about getting gpg to obfuscate it. I wonder if I should make a feature request to the spec team. ;) Can you update your answer with those references so I can mark it as "accepted"? – Wind And Flame Aug 19 '14 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.