OpenPGP Library for Java v3.1.3.6 with a critical bugfix

Today has been released version of DidiSoft OpenPGP Library for Java which provides a critical bug fix.

The bug prevents decrypting .pgp data that was encrypted and compressed with the BZip-2 algorithm. The error message thrown in such cases is:

com.didisoft.pgp.PGPException: I/O problem with stream: Not a BZIP2 marked stream : Not a BZIP2 marked stream : Not a BZIP2 marked stream

Versions affected: all 3.0.x and 3.1.x versions.

Other recent updates

Release date: 08 October 2018
KeyStore class – fixed bug in importing keys with only a comment header line

Release date: 25 September 2018
PGPLib class – default preferred symmetric key cipher is now AES-256, with backward compatibility with keys made prior year 2002 using CAST5
As usual the latest version should be fully backward compatible and the upgrade shall be nothing more than replacing your existing JAR files with those from the latest release.

Shall you have any questions or concerns, please do not hesitate to drop us a line.


GnuPG 2.2.8 compatibility with Java

Recent changes in GnuPG version 2.2.8 in response to the EFAIL attack reject all encrypted data that don’t have Modification Detection Code (MDC) packet.

In order to address this as of version DidiSoft OpenPGP Library for Java exposes a new property in the PGPLib class:


Example usage:

PGPLib pgp = new PGPLib();

Setting this property will have affect on all subsequent encryption or one pass signing and encryption calls that don’t have the integrity check parameter. When the above property is set to true, integrity protection (Modification Detection Code) packet will be added to the encrypted data in the .pgp message to be compatible with GnuPG 2.2.8 and all new upcoming versions.

This change is especially for all methods that produce String output, because in those methods the integrity protection was missing up till now.


Should the EFAIL attack concern your PGP applications

A few days ago in the world of applied cryptography especially S/MIME and PGP emails has appeared a new threat – the EFAIL attack.

In this post we are not going to explain again details of the attack itself as a lot has already been published on the Internet, but rather explain do you have to be concerned using any of the DidiSoft OpenPGP products.

The EFAIL attack in breaf

The EFAIL attack in short consists of allowing the receiver to decrypt the data and send it via HTTP request to the intruder. In the examples published in the source article this is done with an image tag artificial inserted by the intruder and the decrypted data sent as an HTTP request parameter for the image tag location (assumed to be on the intruder’s web host).

The main target of the attack is S/MIME and PGP encrypted email messages.

First approach (image tag)

The first approach they use is by modifying the email and introducing a new body part before the encrypted email body part, which contains an unclosed image tag.

Our proposed Solution

When implementing email rendering do not allow unclosed tags in a MIME section and perform HTML purification independently for each MIME body part.

Second approach (CBC/CFB gadget)

The second technique, named CBC/CFB gadget attack, exploits vulnerabilities in OpenPGP (CVE-2017-17688) and S/MIME (CVE-2017-17689).

From the EFAIL article the reader may conclude that the second vulnerability is something that a 12 year old boy can do at home:

“Given the current state of our research, the CFB gadget attack against PGP only has a success rate of approximately one in three attempts”

The reality tends to be different though. This is still an unconfirmed threat to PGP/MIME emails. The current Security Focus state regarding exploits is “Currently, we are not aware of any working exploits“. PGP/MIME emails with Integrity protection packet cannot be modified as of the time of this writing.

Our proposed Solution

When receiving PGP/MIME emails DidiSoft products will rise exception whether or not integrity protection has been set on the incoming data.

When sending PGP/MIME emails to other entities using DidiSoft products, please ensure that integrity check has been turned on!


The EFAIL attack exploits weaknesses in the implementation of some PGP email clients. The mass press coverage raised uncertainty in organizations relying on PGP encryption, but the attack targets PGP email client implementations and not PGP encryption as a whole.

We also recommend  you to read the one page official answer from the core PGP developers.


Weird symbols in emails to BlackBerry clients

Sending PGP/MIME emails to BlackBerry clients may lead to weird symbols in front of given special characters. This is a hard to be solved bug as it has nothing to do with OpenPGP. The OpenPGP messages created with DidiSoft OpenPGP Library for Java and OpenPGP Library for Android are correct and identical when decrypted up to byte array level with those created with other OpenPGP compatible apps including the BlackBerry PGP support.

One of our clients experienced in his Android app this strange behavior when sending encrypted emails to BlackBerry. Digging deeply in this use case we finally resolved the case to be related to a weird expectation in the PGP/MIME format itself, coded in the BlackBerry PGP support.


Exchanging encrypted data with Bank of America

Bank of America accepts OpenPGP encrypted files from its clients. Unfortunately in the official technical documentation that they provide it is not very clear how to create the proper format which they will accept. In order to easy you we will show bellow a small code snippet that will illustrate how to create such encrypted file with the help of DidiSoft OpenPGP Library for Java. Similar result can be achieved for other programming environments with the corresponding products offered by DidiSoft.

The example code snippet below will create signed and encrypted data in the format requested by Bank of America:

  PGPLib pgp = new PGPLib();
  boolean asciiOutput = true;
  pgp.signAndEncryptFileVersion3("c:\\data.txt", "c:\\my_private_key.asc", "my key password", "c:\\BoA_key.asc", "c:\\encrypted.pgp", asciiOutput);

The key file BoA_key.asc is assumed to be the text file containing Bank of America’s public PGP key. The file my_private_key.asc file shall be your private key corresponding to the public key you have uploaded already to Bank of America. The other parameters shall be self explanatory.


premature end of stream in PartialInputStream

The latest release of DidiSoft OpenPGP Library for .NET ( and OpenPGP Library for Java ( ship with bug fix for the error “premature end of stream in PartialInputStream“.

The error “premature end of stream in PartialInputStream” may be observed when trying to decrypt .pgp data with wrong internal length indicators , usually when the encrypted content is text data. Example of such data can be found at

In order to avoid this error, please make sure that you are using the latest version of the libraries.

The DidiSoft Team.


Using OpenPGP without unlimited JCE policy files

NOTE: This article is Obsolete

As of version 3.0 DidiSoft OpenPGP Library for Java doesn’t need the Unlimited JCE policy files in order to provide full OpenPGP cryptography support!

The default setup of the Java virtual machine (either JDK or JRE) limits some of the ciphers to a certain key strength. The main reason for this is that cryptography is restricted for export by the law in some countries.

A full documentation how to unlock the unlimited Java Cryptography Extensions (JCE) can be found here:

But there may be a situation when you cannot touch the JCE policy files on the client’s machine, for example if you are developing a mass market application. In that case a possible workaround is to limit the number of cryptography algorithms used by your application and still use OpenPGP. If we observe the file : <jre>\lib\security\local_policy.jar\default_local.policy we can see at its end:

permission javax.crypto.CryptoPermission "RSA", *;
permission javax.crypto.CryptoPermission *, 128;

From the above lines we can conclude that we can safely use RSA OpenPGP keys without limitation in the key length. We can also use all the preferred symmetric algorithms that have key size below or equal to 128 bits: AES-128, CAST-5, Blowfish.


What’s the difference between Elliptic Curve OpenPGP keys and AES-256

With the new extension of the OpenPGP Standard that provides support for Elliptic Curve OpenPGP keys we have received a question from one of our customers asking what is the difference between AES-256 and the new ECC OpenPGP keys?

Short answer

The short answer is that the Elliptic Curve cryptography (ECC) OpenPGP keys are asymmetric keys (public and private key) whereas AES-256 works with a symmetric cipher (key).

Long explanation

The long answer is that the new Elliptic Curve cryptography (ECC) OpenPGP keys are designed to replace the existing asymmetric OpenPGP keys which are based on the RSA (both encryption and signing) and Diffie-Hellman (DH) (used for obtaining shared secret) and DSA (used for signature generation).

The ECC keys on the other hand use Elliptic Curve Diffie-Hellman (ECDH) shared secret protocol for encryption and Elliptic Curve Digital Signature Algorithm (ECDSA) for signature generation. An ECC OpenPGP key consists of a master key which is a ECDSA key and a sub key which is a ECDH key and is signed by the master key.

The role of the ECC OpenPGP keys is to encrypt a shared secret known as session key (as each time it is different).

AES-256 as a symmetric cipher is used to actually encrypt the data using the mentioned above session key.

The main reason that the data is not encrypted with the ECDH algorithm is that asymmetric encryption algorithms are much more slower than symmetric ones.


A common confusion is to compare asymmetric encryption algorithms and symmetric ones. In this chapter we have mentioned the new ECC OpenPG keys and the AES-256 algorithm.

You can also check the chapters describing how to specify explicitly the preferred symmetric encryption algorithm with DidiSoft OpenPGP Library:


InvocationTargetException in WebMethods

If you are using DidiSoft OpenPGP Library for Java in a  Software AG WebMethods project you may encounter strange exceptions like:


The reason for such exceptions is that WebMethods ships with an older version of the BouncyCastle jar files and a class loading mismatch occurs.

The resolution is to remove the default BouncyCastle jar files from the WebMethods class path and use only the version that ships with DidiSoft OpenPGP Library for Java.


Migration guide from version 2.5.x to version 2.6

As of version 2.6.0 the plain encrypt methods (PGPLib.encrypt…) throw in addition to com.didisoft.pgp.PGPException.

In order to migrate from version 2.5 you will also have to catch into an additional catch clause.

Methods affected: