Encrypted file-size approximation with multiple recipients
sam.mxracer at gmail.com
Wed Apr 2 04:45:17 CEST 2014
-----BEGIN PGP SIGNED MESSAGE-----
On April 1, 2014 9:01:28 PM EDT, Tim Chase <gnupg at tim.thechases.com> wrote:
>I've been trying to find a good explanation on how something like
> gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt
>works. The best I've been able to find is this:
>I'm mostly interested in the overhead, so I set up 4 distinct
>homedirs for testing. It looks like each additional recipient adds
>about 271 bytes (though one of them only has an extra 270 bytes), and
>there's a per-file overhead of about 66 or 67 bytes.
>So from my experimentation, the final file-size ends up being
> input_file_size + 67 + (271 * recipient_count)
>but I'm not sure how much that might change based on conditions I'm
>not taking into consideration (all my test GPG users were just
>gpg1 at example.com, gpg2 at example.com, etc), all with 2048-bit keys.
>Is there a more formal formula that can be used to approximate the
>overhead of multi-recipient encryption?
After reading in the gpg man page different recipients can have different key sizes. Additionally gpg will look at the supported cipher algorthms of all recipients and attempt to choose an algorithm common between them.
That means your calculations aren't accounting for the different key sizes nor is it accounting for the size of the session key (session key is for the symmetric algo).
You can go about this one of two ways. You can try write a program smart enough to account for that or you can keep it simple.
KISS: assume worst case for every recipient and then do the math. e.g. 4096 bit rsa keys with AES256 cipher algo for the session key (assuming AES256 has the largest session key).
At least that's how I would tackle it.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
-----END PGP SIGNATURE-----
More information about the Gnupg-users