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
cut-off.

> 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".
  
Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gnupg-users mailing list