Is JBIG2 soon banned?
JBIG2 is a compression algorithm for bitonal images and has been developed to replace the widely used CCITT G4 algorithm because it can reach better compression ratios. However, the algorithm has received a bad reputation which has led some security experts to the recommendation not to use the algorithm anymore. Is this a wise advice or just an overreaction? Why could it go so far?
To understand this let us start with some properties of the algorithm itself. JBIG2 can be used in two modes: lossless and lossy. In the lossless mode the decompressed image is binary identical to the image before it is compressed. In lossy mode some pixels may differ in favor of a better compression rate.
To achieve this the compressor builds up a symbol dictionary consisting of bit patterns for e.g. the character "e". On a scanned page this character can appear often, but the bit patterns may differ slightly. The compression algorithm now replaces all occurrences of these patterns with references to the pattern stored in the symbol dictionary. Most compressors have a quality parameter which indicates how "similar" a pattern is to a previously stored symbol. It is obvious that this method can save space.
But, if the quality parameter is set to low then the compressor may replaces a bit pattern for "6" by a reference to the symbol "8". In this case we might get a problem. This possible behavior is the source of the whole discussion about the JBIG2 algorithm.
Due to the problems that might occur during compression some experts recommend not to use the algorithm at all. In particular the German federal authority BSI (Bundesamt für die Sicherheit in der Informationstechnik) revised the RESISCAN guideline accordingly. Although JBIG2 is not mentioned explicitly therein it forbids pattern matching / replacement and soft pattern matching algorithms. This implies that JBIG2 shall not be used neither lossless nor lossy. Also the Swiss KOST (Koordinationsstelle für die dauerhafte Archivierung elektronischer Unterlagen) recommends not to use JBIG2 anymore.
Technically spoken, if a user uses lossless JBIG2 compression then the described problem cannot occur. On the other side I can understand that BSI and KOST recommend not to use the algorithm at all since they assume that most users do no care about the details such as lossy and lossless and quality parameters.
In order to avoid security discussions the setting of the quality parameter has been disabled in our software since version 4.6.5.0 with the effect that only lossless compression is being used.
