This wiki page was recently brought to my attention by Jim Manico, who asked me to review it for accuracy. In doing so, I noticed several errors and areas of weakness.Ultimately, I plan to revise this page (hopefully with the assistance of one of the original owners), but I do not have time to make a complete revision at the present time. Therefore, I will summarize what I see is problematic with the rest of this page and you can decide to use or not, with these caveats.<br>

+

This wiki page was recently brought to my attention by Jim Manico, who asked me to review it for accuracy. In doing so, I noticed several errors and areas of weakness. Ultimately, I plan to revise this page (hopefully with the assistance of one of the original owners), but I do not have time to make a complete revision at the present time. Therefore, I will summarize what I see is problematic with the rest of this page and you can decide to use or not, with these caveats.<br>

#First and foremost, this page does ''not ''describe "digital signatures". Rather, it decribes a concept known as "digital envelopes", which is a scheme used with things like S/MIME. Digital signatures alone never encrypt the actual message text, but only encrypt a ''hash ''of the message text.

#First and foremost, this page does ''not ''describe "digital signatures". Rather, it decribes a concept known as "digital envelopes", which is a scheme used with things like S/MIME. Digital signatures alone never encrypt the actual message text, but only encrypt a ''hash ''of the message text.

Status

WARNING

This wiki page was recently brought to my attention by Jim Manico, who asked me to review it for accuracy. In doing so, I noticed several errors and areas of weakness. Ultimately, I plan to revise this page (hopefully with the assistance of one of the original owners), but I do not have time to make a complete revision at the present time. Therefore, I will summarize what I see is problematic with the rest of this page and you can decide to use or not, with these caveats.

First and foremost, this page does not describe "digital signatures". Rather, it decribes a concept known as "digital envelopes", which is a scheme used with things like S/MIME. Digital signatures alone never encrypt the actual message text, but only encrypt a hash of the message text.

UTF-8 encoding should be used throughout to convert between Java Strings and byte arrays to ensure proper portability across different operating systems.

The certificate chain should always be validated. In the example here, the certificate is self-signed, so this is not relevant, but that will not be true in the normal case. Furthermore, it should be noted that self-signed certificates, while acceptable for demonstration purposes is considered a dubious practice for production as it opens the door for impersonation attacks.

NIST now recommends the use of 2048 bit key size for RSA or DSA keys.

There is a consistent use of weak algorithms. Here are some suggested replacements:

Use "RSA/ECB/OAEPWithSHA1AndMGF1Padding" instead of "RSA/ECB/PKCS1Padding".

Use SHA1 (or better SHA256, but at least SHA1) instead of MD5 for the message digest.

Use "SHA1withRSA" for the signature algorithm rather than "MD5withRSA".

When creating a symmetric cipher to encrypt the plaintext message, use "AES/CBC/PKCS5Padding" and choose a random IV for each plaintext message rather than using simply "AES", which ends up using "AES/ECB/PKCS5Padding". ECB mode is extremely weak for regular plaintext. (It is OK for encrypting random bits though, which is why it is OK to use with RSA.) However, using CBC and PKCS5Padding could make you vulnerable to "padding oracle" attacks, so be careful. You can use ESAPI 2.0's Encryptor to avoid it. (Note also, this is part of the "digital envelope" concept. If this page were truly limited to "digital signatures", it would not apply, as it would be irrelevant.)

I hope to get some time soon to clean up this wiki page. In the meantime, email me if you have questions.

-kevin wall

Overview

This article gives a brief overview of the concepts involved with Digital Signatures and provide code samples for implementing Digital Signatures in Java using the Java Cryptography Architecture.

What is a Digital Signature ?

A Digital Signature is a construct which helps achieve non-repudiation of Origin (ie. Origin Integrity) of data. By digitally signing the document, the person who signs it assures that he is the author of the document or the message that was signed.

Need for Digital Signature

During the "E" revolution, there was a need for authenticating critical transactions especially in the financial World. If Alice has agreed to transfer $x to Bob, then there had to be a way for Bob to be sure that:

It was Alice who performed the transaction and not someone else impersonating Alice (Authentication)

The amount agreed by Alice is $x (Integrity)

Alice could not dispute her statement of transacting $x to Bob (Non-Repudiation of Origin)

These concerns were addressed with a solution known as Digital Signatures. More background information about Digital Signatures can be found on the Wikipedia article

Digital Signatures in Java using JCA

The Java Cryptography Architecture is a framework for accessing and developing cryptographic functionality for the Java platform. A JCA provider implements the cryptographic functionalities like Digital Signatures and Message Digests. The default JCA provider in JDK 1.4.2 is SUN.

Security Considerations while Implementing Digital Signature

Two main Security considerations should be taken into account when implementing Digital Signatures.

Sign the message and then encrypt the signed message

Sign the Hash of the message instead of the entire message

Performance Considerations while Implementing Digital Signature

Since Asymmetric encryption algorithms like RSA, DSA are computationally slower than symmetric encryption algorithms like AES, it is good practice to encrypt the actual message to be transmitted using a Symmetric key Algorithm and then encrypt the key used in the Symmetric Key Algorithm using an Asymmetric Key Algorithm. E.g.: if one wants to transmit the message "Hello World of Digital Signatures", then first encrypt this message using a symmetric key ,say an 128 bit AES key like x7oFaHSPnWxEMiZE/0qYrg and then encrypt this key using an asymmetric key algorithm like RSA.

Algorithm for Implementing Digital signature using RSA Algorithm

The RSA implementation provider in Java has a limitation in that encryption can be done only on data of length <= 117 bytes. If the data is of length > 117 bytes, it would throw an IllegalBlockSizeException : Data must not be longer than 117 bytes Hence the symmetric has to be encrypted and then signed.

The RSA algorithm with PKCS#1 padding can only encrypt data of size k - 11 1, where k is the octet length of the RSA modulus and 11 is amount of bytes used by PCKS#1 v1.5 padding. Hence if we use an RSA key of size 1024 bits, we could encrypt only 128 - 11 => 117 bytes of data. There are 2 options available to encrypt data of larger byte size.

We could use an RSA key of length > 1024. For eg, say if we use 2048 bits, then we could encrypt 256 - 11 => 245 bytes of data. The disadvantage with this approach is that we would not be able to encrypt data of size > x bytes (in the above example x is 245).

Break down the input data into chunks of bytes of size < 117 and apply encryption on each chunk. Code sample for this approach can be found here

Both these approaches would have performance implications since RSA key of larger sizes or a "divide and conquer" approach on input bytes are computationally expensive.

Algorithm

With the above considerations, the algorithm below can be used for implementing public key cryptography in Java.