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!

Conclusion

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.

Read more...

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.

Read more...

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:

1
2
3
4
     
  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.

Read more...

premature end of stream in PartialInputStream

The latest release of DidiSoft OpenPGP Library for .NET (1.7.9.14) and OpenPGP Library for Java (2.6.6.3) 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 http://bouncy-castle.1462172.n4.nabble.com/potential-bug-premature-end-of-stream-exception-in-pgp-message-td4302017.html

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

The DidiSoft Team.

Read more...

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:
https://www.didisoft.com/java-openpgp/examples/setup-guide/jce/

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.

Read more...

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.

Summary

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:

Read more...

InvocationTargetException in WebMethods

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

java.lang.reflect.InvocationTargetException:org.bouncycastle.util.Arrays.constantTimeAreEqual

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.

Read more...

Migration guide from version 2.5.x to version 2.6

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

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

Methods affected:
PGPLib.encryptStream
PGPLib.encryptFile
PGPLib.encryptStreamPBE
PGPLib.encryptFilePBE

Read more...

Unknown KeySpec type ElGamalPrivateKeySpec

Some customers that have deployed DidiSoft OpenPGP Library for Java as part of a web application, have noticed that the exception below is thrown when they perform a hot deploy on the application server:

org.bouncycastle.openpgp.PGPException: Exception constructing key
   at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Source)
   at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Source)

Caused by: java.security.spec.InvalidKeySpecException: Unknown KeySpec type: org.bouncycastle.jce.spec.ElGamalPrivateKeySpec
   at org.bouncycastle.jce.provider.JDKKeyFactory.engineGeneratePrivate(Unknown Source)
   at org.bouncycastle.jce.provider.JDKKeyFactory$ElGamal.engineGeneratePrivate(Unknown Source)


The reason
for the above exceptions is that the library JAR files are bundled with the web application. Hence after an application is stopped/started, they are loaded in another class loader, while the BouncyCastle security provider is already registered with a class loader that is now unavailable (has been destroyed after the web application has stopped).

The solution to this situation is to ship the application without the library JAR files.
They must be placed in a folder shared for all applications running on the Application server.

Below are listed the shared folders for some application servers.

Tomcat 5.x
<tomcat folder>/shared/lib/

Tomcat 6.x
$CATALINA_BASE/lib/

Web Sphere
<was folder>/lib

WebLogic
<weblogic folder>/common/lib

Read more...

unknown object in stream 9

This exception is equivalent to unknown object in stream SymmetricKeyEncrypted. Usually occurs when we try to decrypt a conventionally OpenPGP encrypted file (also known as password encrypted or PBE) that was created with PGP 2.x or McAfee E-Business Server 7.x.

This issue has been addressed in OpenPGP Library for Java version 2.5.6 and upper and OpenPGP Library for .NET 1.7.1 and upper versions. Please update your version in order to resolve this issue.

Read more...