Why does GPG ciphertext length differ with fixed plaintext length?

Question

Thank you for your reply. Based on your inputs. I was investigated further, find details below

Step 1) Input string for encryption is UUID format Input data = c0c6f311-a793-4d65-9374-1c0e45f5382c
Length = 36 bytes Step 2) encrypt UUID with gpg command gpg --encrypt -r PublicKey c0c6f311-a793-4d65-9374-1c0e45f5382c Step3) encrypt gpg output using base64 command /usr/bin/base64 -w 0 gpg-encrypted-data(step2 output)

I had been ran same 36 bytes input data (c0c6f311-a793-4d65-9374-1c0e45f5382c) continuously(90000 times) using step2 and step3, observed below possible outputs

1)gpg encrypted 36 bytes input data to 389 bytes and base64 encrypted 389 bytes input data to 520 bytes -- 89996 times out of 90000 2)gpg encrypted 36 bytes input data to 387 bytes and base64 encrypted 387 bytes input data to 516 bytes -- 4 times out of 90000 3)Able to decrypt the 516 0r 520 bytes encrypted data with orginal Input text(c0c6f311-a793-4d65-9374-1c0e45f5382c)

Please find some of the base64 command outputs gathered from above execution. 520 bytes output last few characters 1) LG1bEwdUt3Sh6ea6cUrDk= 2) Gwpr0kClWzllff6KgNo= 3) FLyCFDlMDQD6GiKJITBIjg= 4) NbJ6y3mayCiWN8yZ9HQsJV+KQ=

516 Bytes Output
1) JpTKn/7yS/0JBhH9TVTRxRNwhmh 2) Vzlo7c2zH2y3kB3PK+ihAyBfA 3) ZlvAgKJQFe39+IT6giO1nQxZcwkX

I have few more questions above execution

Q1) padding is happenings both encryption level(i.e gpg, base64) Q2) is there any way to handle fixed length encryption? Q3) is there any way to remove padding encryption in both levels(i.e gpg, base64)? Q4)Actually we are assuming that base64 encryption happening with 520 bytes, even above execution also 99% encrypted with 520 bytes. Is there any way to padding 516 bytes encrypt to 520 bytes encryption?

Answer 1

TL;DR: There are different possibilities: A timestamp is included before compression, and can result in slightly different compressed message lengths. The encrypted session key is stored as multi-precision integers, which are of dynamic length. Finally, ASCII-armoring adds a padding that might enlarge the size difference slightly.

Compression and Timestamps

When using OpenPGP, different operations are performed one ofter the other, you could compare them to multiple layers put around the original data. The message is wrapped with some meta information (the "literal data packet"), then compressed, finally encrypted. Often there are different alternatives in the individual steps, but in the end it mostly boils down to these operations. I especially ignore the fact OpenPGP is a hybrid cryptosystem, as this adds complexity but is not relevant to this question.

Using a kind of formula notation, you can simplify the operations as

encrypt(compress(literal(message, filename, timestamp)))

If you observe this, you will realize repeatedly encrypting the same message will always return another result: the timestamp is also contained as message metadata (there's also some randomness in choosing symmetric keys, but that's another story that leads to completely different crypto texts). As the timestamp is also subject to compression, different timestamps might compress worse or better, this can indeed lead to minor differences in the size of the encrypted message.

faketime

This might or might not be the only reason, but you should be able to easily evaluate using the handy faketime tool available for probably all unixoid systems. Most Linux distributions include it in their packet managers. It sets a fixed system time for the application executed. If the timestamp is the only reason for different message sizes, you should get messages of the same size now:

faketime 2015-12-02 gpg --encrypt ...

Multi Precision Integers and Session Key

The encrypted random session key used for encryption of the message is stored as multi precision integers, which do not have fixed length. Although these session keys are expected to be of similar size, the might be rare cases (one out of 256) that the encrypted key has all first 8 bits set to 0: as a result, the result can be stored with one byte less (and still being the same number). In very rare cases this might even lead to multi-byte differences.

ASCII armoring

Finally, ASCII armoring cannot be the reason for different sizes, but can enforce already existing differences because of padding the output to multiple of three bytes, adding up to two bytes if necessary (resulting in a message larger by only a single byte being padded by up two additional bytes).

Answer 2

Each new PGP encryption is done with a new symmetric cipher key called session key and generated randomly. The binary encrypted output is then transformed to ASCII armored format, which converts binary data to ASCII characters and depending on the last data length may produce 1 or 3 bytes (Check here for more: PGP RFC: Converting to Radix-64)