You really want to understand us. Great !

Digital Signatures

Before we start, it's important to clarify that all of the following is done totally automatically by the system. You don't need to do anything at all for all this to work, and you don't need to understand it. But, since you asked...

OK, so first we need to understand that digital signatures are not like signing a bit of paper. Instead, they use the same public/private key pairs we've been talking about to do the following:

• provide proof that the package was created by the sender
• allow a receiver to prove that an encrypted file was created by a sender
• provide proof that they package was not modified after creation

Now, the first two items sound like they're the same thing, but they aren't really. The first one gives the receiver confidence that the file was created by a particular sender, and not by someone else pretending to be that person. On the other hand, the second allows the user to prove that the sender did indeed create the package, or as we say, does not allow the creator to deny creating the package. We call this non-repudiation.

The third item is self-explanatory – it would not be very useful if we knew and could prove that the package was created by someone if the package could have been modified by someone else in the interim.

So, how does this work? Well, basically, it uses two cryptographic functions, one of which we have already discussed, asymmetric encryption. But first, we need to undertand another cryptographic process: hashing.

Hashing is basically taking some data, and doing a really complex series of calculations on the individual parts of it to derive a long number. A really simple hash (which would be useless for cryptography) would simply involve adding the numerical value of each character, and just overflow the result to a certain size. You can see that changing a character would result in a different number. The problem with this simple hash is that there are MANY ways to come up with the same result, and it is relatively easy to change the data so as to leave the result unchanged – such as simply swapping two digits.

So, we don't do that. No, seriously, nobody does that.

Instead, some really, really smart mathematicians have come up with a complex series of calculations, where previous data parts affect later ones in a complex orchestration of additions, rotations, shifts and so on. The result is a 256-bit number. To understand how big that is, in normal decimal notation it would contain about 77 digits. Let's just agree that it's quite large.

But it's not just that these hashing calculations result in a big number. They also have a couple of other attributes

• Even a change to a single bit (like, changing a 0 to a 1) will result in a totally different result.
• The result from processing any given data is randomly spread across the entire range of possible values (so we don't have a lot of digits but only a few of them actually change)

In practical terms, these attributes, combined with the large number of possible results, makes it impractical to create a different set of data that when processed through those calculations, will come up with the same result. To do that with a set of data that still makes sense (for example, can still be read as text, or opened by a program) would, for all intents and purposes, be impossible.

The best-practice cryptographic hash process currently in use is called SHA-256, and that is what the Securetly system uses. We say that we derive an SHA-256 hash which is just a concise way to way we use the SHA-256 algorithm (process) to generate a 256-bit number from the data package.

So, all very interesting, but what does that have to do with signatures?

Glad you asked! Recall that when you create a package to send, it is encrypted with the recipient's public key, which means that it can only be decrypted using the matching private key, which only the recipient has.

However, you may recall that the keys can also be used in reverse – if you encrypt something with a private key, then it can be decrypted with the matching private key (and only with the private key).

So, creating a digital signature is a three-step process:

• After we've created the package, we derive an SHA-256 hash of that package. (See what we did there?)
• Then we encrypt that hash (the 256-bit number) with our private key
• Finally, we add that to the package

Now, when the receiver gets the package, he or she will retrieve the encypted hash from the package, and then will re-derive the hash from the rest of the package. Because SHA-256 is a standard process, the result will be exactly the same as the one generated by the sender, but only if that package has not changed in any way, not even by the tiniest amount. The receiver then looks up the sender's public key, and uses that to decrypt the encrypted hash that was part of the package. If the decrypted value matches the calculated value, then we can be certain that:

• The package has not been changed after it left the sender
  (because if it had, the hash would now be different)
• The encryption of the hash was indeed performed by the sender
  (because nobody else has the private key that would allow the hash to be decrypted with the sender's public key)

A matching encrypted hash (which we call a verified signature) means that the receiver can prove that the package was created by a particular sender (and was not changed after it was signed) – sort of like having a signed contract.

Again. let's remember that this is all done automatically by the Securetly software – you don't need to do anything extra. Packages you send will automatically be signed, and packages you receive will have their signatures verified. If a verification fails, you will be warned that the package may not be from who you think or may have been tampered with – it's up to you to decide what to do next.

We're happy to talk to you about how the system works, and to find out if there's anything more you need to know to help you evaluate whether the Securetly service is right for you and your organisation. No sales talk – communicate directly with our technical team by sending an email to dev@securetly.com