Encrypted file-size approximation with multiple recipients
Sam Gleske
sam.mxracer at gmail.com
Wed Apr 2 04:45:17 CEST 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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:
>
>http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html
>
>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
>something like
>
> 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?
>
>Thanks,
>
>-tkc
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.
SAM
- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQJABAEBCgAqBQJTO3m9IxxTYW0gR2xlc2tlIDxzYW0ubXhyYWNlckBnbWFpbC5j
b20+AAoJEOj3MjRyV+ZfwtgP/2USc47Fsf6zk6qEq/ZbImdIhjZubhx8CDomkTz7
GKXzOGwHpWVC+WtUNI9Dm8L1LKe4vT/WBTbjLIMqF963ds4MAR5abQk/aRsf8COV
pkjuY+FYEkcyQC0+1RWVQBakxm7Vp3WVLOOO5rlaj/5DULYhYiM7tEYPNR+Zk3ew
dxf/27we6OTzWClVwGEYQ0R4uIyo5f7OyRpzLrRgvWZhds8zQW1ha2oNMQLupHll
ZCibhNQ7W0rROqqk755c8lvlCSHz61g3IDvGQlpFWqo3iRVLJcW1/qa2Nz0Q0W3G
M/CK7kW1R51Wp0/esN0qNo5+lFyt60c3BQSFBBm1RS7T72bo34KIjY0G9ytccaIp
WhyTkVKZMx+kgpuFWsE5Ege+q42Wii3cNf1si0O2Iz72w9ckLBcNHj5ax1ndIm5o
Ir1jx759+yPd2Jg+ctOeY+XKXOMgHxOygYRX6IPUYqm5+4aO4pUijIs5s6wge1+7
okseitw7/qvX0i7jr0DKLXUDYVYuuBvaBWiJs5gtJeKMFTl/tR5qLV4A0hTdKdPw
2p4Eb9Nm/w5FYUbQq/yAFpD2HHEN3MmCE40zpAGaDAGWCTN7FrJFo9tWhenyenhi
bL0YPZ/OCeoFlg9QodaXiNLy5DwBp5DKx0dgJmxrAPU7LE7I5h/cGe3ShXelqxRq
auFu
=ku2m
-----END PGP SIGNATURE-----
More information about the Gnupg-users
mailing list