site coming soon logo

So, you want some more details. We like that !

Modern encryption can be very strong, and virtually impossible to break. After all, we rely on it every day to secure communications with our bank and other commercial institutions. Use eBay or Amazon? Paypal, Stripe or Square? Pay your bills or access your bank account online? Use GMail? All of these rely on modern encryption.

It is true that we hear about security breaches all the time. However, that is generally caused by systems being hacked, not by encryption being broken. Generally, criminals gain access to sensitive data by tricking people into revealing passwords (using social engineering or phishing attacks) and then accessing databases that store data unencrypted or, in thankfully now infrequent cases, by getting into password databases that store passwords rather than hashes.

So, encryption works – it's a solved problem and we know how to do it. However, for encryption to be bulletproof, it needs to be done properly. Amongst other considerations, it is imperative that:

So, how do we do ensure that we do encryption right?

It turns out that it's really not that difficult, just inconvenient to manage. Below is the high-level explanation of how these requirements can be met and how the Securetly system works.

First, we need to undertand the difference between symmetric and asymmetric encryption.

Symmetric encryption is the one you are probably more familiar with. In symmetric encryption, the same key (or password) is used both to encrypt a file and then to decrypt it. By definition, both the sender and the receiver need to know the key, which itself needs to be communicated using a separate, secure mechanism. Symmetric encryption can be very strong, provided that the key is sufficiently long and complex and of course that it is kept secure and not exposed when communicating it between the sender and the receiver. It is also generally quite fast.

Asymmetric encryption is quite different. The maths is quite complex and not something we're going to get into here; the good news is that the concept is easy to understand without needing to understand the underlying mathematics.

With asymmetric encryption, there are two keys involved. These keys are generated by a complex process that creates a pair of keys that have the following properties:

So, how does asymmetric encryption help us?

Because of the nature of how asymmetric keys work, we can designate one of the keys as a PUBLIC key, and the other one as a PRIVATE (or sometimes called SECRET) key. We keep the PRIVATE key secret – we don't share it with anyone, ever, and we keep it secure on our own computer.

In contrast, the other key in the pair, which we will call the PUBLIC one, is published for all the world to see. We don't even try to keep it secret. Not only is that not required, it would actually limit the usefulness of the system.

Now, if you want to send me an encrypted file, you look up my published, PUBLIC key and use it to encrypt the file, all on your computer. You then get that encrypted file to me any way you like – you don't need to worry about security, because the only key that can decrypt the file is the matching PRIVATE key, that only I have.

When I get the file on my computer, I use my PRIVATE key to decrypt it. Simple, elegant and removes the need to communicate any secrets between the you and me. No need to send me the encryption key over SMS only to have me try to type it correctly into the decryption software.

As a side benefit, assuming that you, as the sender, also have a public/private key pair (obviously, a different pair!), it is possible for the you to use your PRIVATE key (which you will remember only you have, and you have never shared if with anyone) to digitally sign the file (or indeed, a simple message). I, as the receiver, can then look up the your PUBLIC key and use that to verify the signature.

So, it all sounds really good, right? So how come we're not using it everywhere?

Well, we are using asymmetric encryption – a lot – but it's often not visible to you as an end-user. The reason it's not used a lot by end-users is because of some of the other attributes of symmetric encryption:

However, these difficulties can be addressed. Here's how Securetly does it.

During program setup, our program generates a unique PRIVATE/PUBLIC key pair on your computer. Both keys are stored safely on your computer, encrypted with a pass phrase that you provide (which you must NOT forget as we cannot get it back for you!). Additionally, your PUBLIC key, and only your public key, is sent to and stored on the Securetly servers, associated with your email address (which we have verified with you ahead of time). The system manages the keys for you automatically, correctly and securely.

To encrypt a set of files, those files are first compressed into a single archive, something like (but not actually) a ZIP file. Then, that archive is encrypted using a new, totally random, very long and complex symmetric key. Remember, this is fast and secure, and the key is only used once because a new random key is generated for each encryption.

The receiver's PUBLIC key is then looked up on the Securetly server. This is why we need receivers to be registered too – we don't charge for users who only receive files.

Then, the symmetric encryption key is itself encrypted using the receiver's PUBLIC key. As the symmetric key is short (in comparison to the file size; it's still long for a key!), this is quick and efficient. If the receiver has registered multiple keys (because he or she uses multiple computers), the symmetric encryption key is encrypted separately with each of the receiver's public keys.

The encrypted archive is "signed" with the sender's PRIVATE key. This uses a combination of cryptographic hashing and asymmetric encryption to create a file that can be used to verify who created the file and that the file has not been modified since creation. The signature file can then be used by the receiver, together with the sender's PUBLIC key, to perform that validation.

We have a separate page explaining how digital signatures work if you want to know more, but don't stress it – this is not a core feature of the system.

Finally, the complete set of files (the encrypted archive, each version of the encypted symmetric key, and the digital signature) is packaged up into a single .lockbox file, ready to be sent to the receiver.

On the other end, the program on the receiver's computer unpacks the .lockbox file and, after looking up the sender's PUBLIC key from the Securetly servers, verifies the signature. If it does not verify, the receiver is warned about this and given the choice about whether or not to proceed.

The receiver then uses whichever of his or her PRIVATE keys are available on the local computer to decrypt the symmetric key, which then in turn is used to decrypt the archive. It is finally unpacked into a chosen directory on the computer.

So, that's pretty much it. Obviously, we've glossed over some of the details, but the above should give you a good understanding both about encryption in general, and how the Securetly system works.

Some additional notes for the real techos...

We use 4096-bit key pairs, as well as 4096-bit symmetric keys, well above the accepted best practice of 2048 bits.

All keys are stored (both locally and on the server) in standard PEM format.

Keys are stored locally encrypted with a user-supplied password. We enforce a minimum password length of 16 characters, and in conformance with current best practice do not require that they be changed on any particular cycle. The system (and indeed, any system) cannot protect from a compromised workstation – Securetly creates archives that are securely encrypted using state-of-the-art technology, but if a workstation is compromised, then attackers likely have access to the unencrypted source data even without the need to access the encrypted archives.

On the servers, keys are not encrypted. Indeed, we provide a simple https JSON end-point to retrieve a list of any user's public keys. That's actually part of the security of the system. We keep no sensitive data on the servers, and all payments are handled through Stripe.

Each key pair is associated with a key alias (we recommend the computer name as a good option) and this alias is stored in the local password store and on the servers. It is also encoded into the encrypted symmetric keys packaged in the .lockbox file, allowing the receiver to easily select the correct encrypted symmetric key.

This whole ecosystem, where a user is allowed to have multiple key pairs active, is to make it easy and transparent to use multiple computers without the need for the user to move keys from one computer to another – this is often both a point of confusion and a time where private keys can accidentally be exposed.

All multiple encryptions (especially, the multiple encryption of the symmetric encryption key) add a significant salt to prevent statistical attacks, even though these are unlikely, due to the random nature of the payload.

The system also allows the user to easily delete unused keys, or to revoke them to allow old files to be processed while ensuring that signatures generated using those keys are flagged appropriately.

The application is not a web application because it is necessary to have free access to the files on the local computer. It is made up of two components, a cross-platform server process that handles all the encryption as well as communication with the Securetly servers, and a separate GUI application that provides the user interface. This allows us to support Windows, Mac OSX and Linux efficiently. It is also why you will see two processes running when this application is executing.

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