Encrypted file-size approximation with multiple recipients

[Tim Chase]

On 2014-04-02 00:37, David Shaw wrote:
> This can change pretty significantly given different key lengths,
> different algorithms, and perhaps most significantly, how
> compressible the original document is (by default GPG compresses
> data before encryption).  An input file of text will compress very
> differently than an input file that's a jpeg (as jpegs are already
> compressed, and so do not benefit much from a second layer of
> compression).

Thanks both to David & Sam for their replies.  While not exact
answers/formulas, they were both quite helpful:

1) I'd missed that GPG conveniently compresses the data before
encrypting which would explain some of the differences I saw.

2) getting a rough worst-case bound (larger RSA keys and algorithm
choice can impact) for per-recipient overhead.

It also helps come to terms with the fact that, in more than half of
my use cases (small plain-text/JSON messages), the multi-recipient
overhead will swamp the size of the actual compressed+encrypted
content.  A fact that I can live with, but is nice to know up front.

Given that the recipients are in pre-defined groups would it make
more sense to multi-recipient-encrypt a single unique group-key, and
then encrypt all messages for that group with the given key?  I do
see the possibility of a trust-leak where a group member could
decrypt the group key and then provide it to other non-group members,
but if that's the case, the untrustworthy group member could just
decrypt the messages and provide those directly.  That's a risk I'm
willing to accept.  Since it's wrapped in my program/code, I can
automate the group-key fetching from a UI perspective.  I'm mostly
interested in things like regenerating the group key when group
members are removed, or adding additional group members to an
existing key, as well as any "good golly, man, that's idiotic because
of XYZ" warnings it might entail.

Thanks,

-Tim