Signing & Encryption

cobra:signer Digital Documents Signing, Encryption and Validation

In cases of documents communication, digital signatures and public key cryptography is utilized to reassure data integrity and non‐repudiation. Using these technological principles, cobra:signer enables the sender of the document to authenticate himself/herself to the receiver (so the receiver knows that it is really the sender who sent the message).

Digital Signing

In order to send a document, the sender utilizes the signing functionality of cobra:signer so as to apply his/her own digital signature to the document, using his/her private key to encrypt a digest of the document and append it to the actual document. At the receiving end, the reverse procedure is followed, according to which the document is separated from its hashed digest. Then, the document is also hashed and the digest is decrypted using the public key of the sender. If the two hashes are identical, the signature is valid. For the purposes of digital signing, the users of cobra:signer have to use a pair of personal public-private keys, stored in a hardware security module (like a USB stick or smart card). The public keys of the users exist in the form of digital certificates, which are digital documents that bind these public keys to the actual owner signed by a certification authority.


In order to reassure data privacy, cobra:signer adopts an asymmetric encryption approach using the pair of public-private keys of the receiver. In particular, cobra:signer allows end-users to encrypt, store and exchange documents using the public key of the receiver. These documents can only be decrypted by the holder of the paired private key (i.e. the receiver), in order to ensure that documents sent are only accessed by the authorized person, who holds the paired private key.

Technical Characteristics

cobra:signer constitutes a custom-made software for documents digital signing and encryption, employing the Java Web Start technology that is a helper application that is associated with a Web browser and enables standalone Java software applications to be deployed on the Web. When a user clicks on a link that points to a special launch file (i.e. a JNLP file), it causes the browser to launch Java Web Start, which then automatically downloads, caches, and runs the given Java‐based application. The entire process is completed without requiring any interaction of the user, except for the initial single click. From a technology standpoint, Java Web Start inherits a number of key benefits to cobra:signer:

  • fully automated, Web‐centric distribution and installation of Java 2 applications, applets, and extensions based on the JNLP.
  • resource caching: application components are cached automatically on the client’s machine.
  • browser independence: applications are executed outside of the browser process and can also be launched directly from the desktop.
  • JVM [Java Virtual Machine] independence: a pre‐requisite virtual machine implementation and version can be specified and, if not already present on the client’s machine, they are downloaded and installed automatically.
  • transparent updating: versions of cached application resources are checked against those hosted on the Web server. Newer versions are downloaded and installed automatically.
  • Incremental updates: only new or modified classes and resources need to be uploaded to the client’s machine.

Encrypting a Document

To use a digital signature or encryption you must have a digital id also known as a digital certificate.  A digital id/digital certificate used to do two things.  First, it can be used to do email encryption or encrypt files so that they can only be read by the person they are intended for.  Second, it can be used to “sign” or place a digital signature on a document to guarantee that it arrives in the same state it was originally sent and no one has added or changed things.


A digital id or digital certificate consists of a public and private key.  Your public key is shared with everyone.  Your private key is kept private.  These keys are text documents full of what appears to be random numbers and letters, but with the proper algorithm, these numbers and letters have a very unique property.


If you take a document and run it through an algorithm with your public key, you get back an encrypted document or an encrypted email.


Once it is encrypted, the public key can’t be used to decrypt the document. The process is one way so it doesn’t matter if other people have the public key, they can’t read the document.


To decrypt the document you must have the private key.  If you give the encrypted document to an algorithm with the private key, you will get back the original document.

An Email Encryption Example


Lets start with Tom and Suzie.  They want to communicate securely to keep Hitler from reading their messages. They are going to use email encryption to communicate.

tom-sends-public-keyFirst Tom, sends Suzie his public key.  This usually happens automatically when Tom sends Suzie a normal email message.  Their email programs handle sending Tom’s key and recording it on Suzie’s side of things. When Suzie sends Tom a regular message, Tom gets her key as well.


Suzie takes Tom’s public key and uses it to encrypt an important message.  Then she emails the encrypted message to Tom.


But wait! Hitler intercepts the message by infiltrating Suzie’s ISP and breaking into her email.  He now has the encrypted email message that Suzie sent to Tom.  Hitler also has Tom’s public key that Tom sent to Suzie.  However, no matter what Hitler does with the public key, he can’t decrypt the message.  The only thing that can decrypt the message is the private key that Tom keeps safe. Email encryption prevents Hitler from reading the message–even though he has a copy of the email that was transmitted over the internet.


When Tom gets the message from Suzy, he takes his private key and uses that to decrypt the message.  He can now read Suzie’s email.  It doesn’t matter who else gets a copy of the email that Suzie sent. Email encryption insures that Tom is the only one who can unlock it as long has he doesn’t share his private key.  If he wants to reply to Suzie, he simply uses her public key to encrypt his reply and sends it back to her.

Signing a Document with a Digital Signature

With an understanding of how documents can be encrypted, we can look at how to “sign” a document using a digital signature.  This is very different than a scanned signature that merely attaches an image of your written signature to a document or email. An encrypted document does two things.

  1. It guarantees that the document wasn’t modified in route.
  2. It guarantees that no one else can read the document.

For a lot of communication, item two isn’t necessary or even desired.  For example, if I want to send a message out to 25 people, chances are pretty high that it isn’t extremely confidential.  In fact, sending a separate message to each person encrypted with their public key might be quite a burden.  However, I still may want each recipient to be guaranteed that the document came from me and that it wasn’t modified in transit–we want to put a digital signature on it that says guarantees who sent it and that it wasn’t modified.

Outside of signed email, I may want to post a message on a website that can be read by the world where anyone can check to make sure that the message hasn’t been changed from when I wrote it and confirm that it was truly written by me.  A slightly different example of this is when a company posts a piece of software or a patch for existing software.  The people who will download it  want some way to know that they are getting a legitimate file and not a virus that was posted by hackers to trick people.