Encryption File Size

Werner Koch wk at gnupg.org
Fri Feb 24 14:35:43 CET 2012

On Fri, 24 Feb 2012 11:19, peter at digitalbrains.com said:

> And *if* (big if) there isn't an acceptable worst-case overhead for a
> compression algorithm, there is probably a cut-off in GnuPG, or it would

No there is none.  As a proper Unix tool gpg works fine in a pipeline
and thus can't roll back a large amount of data to implement such a

> become a DoS attack vector: get someone to encrypt a specially crafted
> file that will fill his filesystem when the compression algorithm is run

There is an optional cut-off option for for decompression:

  @item --max-output @code{n}

  This option sets a limit on the number of bytes that will be generated
  when processing a file. Since OpenPGP supports various levels of
  compression, it is possible that the plaintext of a given message may be
  significantly larger than the original OpenPGP message. While GnuPG
  works properly with such messages, there is often a desire to set a
  maximum file size that will be generated before processing is forced to
  stop by the OS limits. Defaults to 0, which means "no limit".


Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-users mailing list