3
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ Cross-post $\endgroup$ – unor Dec 1 '15 at 11:24
  • 1
    $\begingroup$ Are you always encrypting the exact same bytes? $\endgroup$ – Henno Brandsma Dec 1 '15 at 15:45
  • $\begingroup$ yes we are encrypted same data(36 bytes) continously $\endgroup$ – Harinath GI Dec 2 '15 at 6:27
  • $\begingroup$ Just a remark: base64 is not encryption, just a standard way to transfer/display binary data as text data. $\endgroup$ – Henno Brandsma Dec 11 '15 at 8:06
  • $\begingroup$ Can you give the complete gpg command ? Giving the string on the command line interprets it as a filename, so you must do something else. All details can matter. $\endgroup$ – Henno Brandsma Dec 11 '15 at 8:16
3
$\begingroup$

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

$\endgroup$
  • $\begingroup$ There may be another reason: GPG could use a variable number of octets to store a multiprecision integer. Sometimes, the encrypted session key might be a lower number that does not take as many octets to store. $\endgroup$ – sellibitze Dec 3 '15 at 16:23
  • $\begingroup$ Indeed. I was sure OpenPGP wouldn't prune the unencrypted session key to not weaken the key space (information on the most significant bits could have been revealed), but of course they can safely do for the encrypted session key. $\endgroup$ – Jens Erat Dec 3 '15 at 16:32
  • $\begingroup$ Thanks Jens for your valuable inputs, i have changed issue description, could you please give your inputs and suggestions $\endgroup$ – Harinath GI Dec 11 '15 at 5:10
  • $\begingroup$ Please take use of the broad formatting capabilities, a dump of paragraphs intermixed with commands, output and lists is unreadable. The FAQ explains what is possible in-detail. $\endgroup$ – Jens Erat Dec 11 '15 at 11:09
0
$\begingroup$

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)

$\endgroup$
  • $\begingroup$ As far as I can tell, you did not mention anything that would be responsible for a change in length of the output. ASCII amoring is irrelevalt since the length of the ASCII version only depends on the number of bytes. $\endgroup$ – sellibitze Dec 3 '15 at 16:11
  • $\begingroup$ This is not completely wrong, but can only enforce already existing size differences. $\endgroup$ – Jens Erat Dec 3 '15 at 16:42
  • $\begingroup$ Thanks Peter for your valuable inputs, i have changed issue description, could you please give your inputs and suggestions $\endgroup$ – Harinath GI Dec 11 '15 at 5:13

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.