DidiSoft Ltd. company news, events and announcements.

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 3.1.3.2 DidiSoft OpenPGP Library for Java exposes a new property in the PGPLib class:

PGPLib.isIntegrityProtectArchives()
PGPLib.setIntegrityProtectArchives(boolean)

Example usage:

PGPLib pgp = new PGPLib();
pgp.setIntegrityProtectArchives(true);

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.

Read more...

GnuPG 2.2.8 compatibility for .NET

As of version 2.2.8, GnuPG/gpg will not accept encrypted or signed and encrypted .pgp files which don’t have integrity protection packet, also known as Modification detection code (MDC packet). This will be the default behavior of GnuPG from now on, and is their answer to the EFAIL attack.

Our product OpenPGP Library for .NET exposes methods which allow explicit setting of the integrity protection packet. But up till now the methods where this parameter was absent didn’t used integrity protection and the output from them will not be accepted by all new versions of GnuPG. This applies also to all methods that deal with output as String type.

In order to address this issue, version 1.8.4 of DidiSoft OpenPGP Library for .NET  exposes a new property of the PGPLib class : PGPLib.IntegrityProtectArchives. Sample usage is :

PGPLib pgp = new PGPLib();
pgp.IntegrityProtectArchives = true;

This code block will ensure that all subsequent operations where Integrity protection is not specified explicitly will use it and the output will be accepted from GnuPG 2.2.8 and upper versions. The same applies to Symantec PGP Command Line 10.4.2 and newer versions.

Read more...

Compatibility with Java 7+ RSA signatures

As of Java version 7 and above the RSA digital signatures computation has been changed and signatures that were previously accepted by software build with Java may end being rejected with message like: “unable to verify signature: Signature length not correct: got 511 but was expecting 512

Solutions using DidiSoft OpenPGP Library for .NET may be affected when they send signed or signed and encrypted PGP data with software systems build in Java. A recent example we had was with TIBCO MFT, throwing the above mentioned error.

The technical explanation of the problem is that a digital signature consists of MPI (multi precision integers) which are kept in array of bits (not bytes!) and when serialized they may end being less then a number power of two.

Version 1.8.3.5 of OpenPGP Library for .NET resolves this issue by padding with leading zero bytes up to a length power of two. If you encounter such behavior then please upgrade.

Read more...

OraSFTP v 1.2.6 now supports current remote folder

DidiSoft OraSFTP prior to version 1.2.6 were limited to either absolute paths or paths relative from the current user remote home directory.

As of version 1.2.6 the current remote folder can be changed this way allowing for easy traversing and manipulation of complex remote folder structures.

The new methods that support this functionality are:

ORA_SFTP.CURRENT_DIRECTORY – retrieves the absolute path of the current remote folder

ORA_SFTP.PWD – alias of ORA_SFTP.CURRENT_DIRECTORY

ORA_SFTP.CD – changes the current remote folder

ORA_SFTP.CD_UP – changes the current remote folder one level up

You can see example usage at:

https://www.didisoft.com/ora-sftp/tutorial/#pwd

Read more...

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

Update to DidiSoft Privacy Policy

The new European General Data Protection Regulation (GDPR) goes into effect on May 25, 2018. We can assure you that all DidiSoft services are fully compliant with GDPR as of today.

Not only is GDPR an important step in protecting the fundamental right to privacy for European citizens, it also raises the bar for data protection, security, and compliance in the industry.

The main three steps we have performed were to ensure that the customers’ data in our database is encrypted, to give you information for all the data we store for you and to ensure the right to erasure (to be forgotten).

Where can I see my data

In our customers’ section you will find a menu GDPR which displays all the information we have for you and your company.

Right to erasure (Act. 17 of GDPR)

In our customers’ section you will find a menu GDPR and a button at the bottom “Delete all my data”.  From there you can erase forever the data we store for you. You can also contact our support department and we can do that for you.

Read more...

Should DidiSoft OpenPGP Library for .NET provide strong name assemblies or unsigned assemblies?

Last week we have sent a short survey to subscribers for our OpenPGP Library for .NET mailing list. The survey had only one question:

Should DidiSoft OpenPGP Library for .NET provide strong name (signed) assemblies (DLL’s) or plain unsigned assemblies?

At the end of this post you will find the results of the survey, but first lets explain why did we made it.

DidiSoft OpenPGP Library for .NET was providing limited PGP emails support due to limitations in the System.Net.Mail namespace implementation regarding the MIME email formats (in fact we supported only PGP-inline emails). Recently we had received a numerous requests for additional support for PGP/MIME email format. In order to implement it we decided to use the open source MimeKit library but this is the moment where we were hit with this case:

+-------+        +---+         +--------+
|   B   +------->+ A +<--------+    D   |
+---+---+        +---+         +--------+
^                               ^
|                               |
|                               |
+---+---+                       +---+---+
|  C.1  |                       |  C.2  |
+-------+                       +-------+

Assembly A needs to use assemblies B and D, which reference different versions of assembly C. Of course this can be resolved with binding redirect in the app.config or dynamically in the AppDomain.CurrentDomain.AssemblyResolve event. But our aim was to provide a DidiSoft.Pgp.Mail.dll which use will be as simple as just referencing it straight away.

Digging for more information in Stackoverflow and MSDN we found out that probably the days when strong named assemblies were a must may have passed away. In order to hear what our community thinks we decided to file the survey. And here are the results:

The results are self explanatory – we must provide both strong named DLLs and unsigned too.

 

Read more...

Merry Xmas and a Happy New Year 2016

We say “Thank you” to all customers and partners for the excellent cooperation and loyalty during the last year.

The entire DidiSoft wish you and your family a happy and healthy holiday season and a prosperous 2016!

Your DidiSoft team

Read more...

OpenPGP standards and references

This page contains a list of public standards related to OpenPGP

Current OpenPGP standard

RFC 4880 – OpenPGP Message format
https://tools.ietf.org/html/rfc4880

RFC 3165 – PGP/MIME
https://tools.ietf.org/html/rfc3156

RFC 6637 – ECC (Elliptic Curve Cryptography) in OpenPGP
https://tools.ietf.org/html/rfc6637

RFC 5581 – Camellia cipher in OpenPGP
https://tools.ietf.org/html/rfc5581

Draft specifications 

SHA-3 in OpenPGP
https://tools.ietf.org/html/draft-jivsov-openpgp-sha3-01

Using DANE to Associate OpenPGP public keys with email addresses
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-06

OpenPGP HTTP keyserver protocol
https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00

OpenPGP Web Key service
https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-00.txt

Obsolete standards

RFC 1991 – The old OpenPGP message format
https://www.ietf.org/rfc/rfc1991.txt

Read more...