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

McAfee EBusiness Server 7.1 error -11391

If you encrypt data for recipients that use McAfee EBusiness Server 7.1 you may receive complaints that they cannot decrypt the file. Below is a common log if the other party uses info level VERBOSE (with command line parameter –info VERBOSE or in the pgp.cfg file):

Enter pass phrase:
event 23: Decryption

symmetric cipher used: CAST5
event 3: error -11391
event 2: final
Error decrypting file ‘test.pgp’.
Corrupt data.
bad packet

exitcode = 32

In order to create compatible encrypted messages with DidiSoft OpenPGP Library for .NET and OpenPGP Library for Java, please set explicitly the PGPLib class to use  ZIP compression before encrypting (if you have changed it to something else). Refer to the online documentation below for examples how to do it:

Set compression in OpenPGP Library for Java

Set compression in OpenPGP Library for .NET

Drop us a line if your recipients still have trouble decrypting a file that you have encrypted with our products.

Read more...