End-to-End Encryption is an implementation of encryption. It is a method of encrypting data at the absolute soonest possible point in time and decrypting the data only at the very last possible moment. The encryption algorithm used when encrypting/decrypting is irrelevant to the definition of End-to-End Encryption. Using End-to-End Encryption means that the data is encrypted as it travels through the internet (in transit), to application servers, into databases (at rest), and out of databases, to be processed. This insures that the data is encrypted and the plain-text version is not available to DBA’s, Developers, Network Engineers, Managers, Unix/Windows Administrators, Help Desk Personnel, Storage Administrators, Security Personnel, etc. End-to-End Encryption is considered the best and most secure implementation of encryption.
A very simple example… data is encrypted by the sender as soon as the message is composed. It is encrypted as it flows to an email application on the sender’s computer. It is encrypted as it flows through the sender’s router, through the internet (and all that that entails), to the recipient’s router. It’s encrypted as it rests within the recipient’s email application. It is only decrypted just prior to the recipient reading the message.
Here’s an example that one may find in an enterprise… A credit card number (let’s call it a PAN for Primary Account Number) is encrypted by javascript in the browser just after the Submit button is pressed. The cyphertext (encrypted data) is http posted to an app server, and the app server updates a column in a database. The PAN is encrypted ASAP in this example.
To use the PAN in the above example, the cyphertext is copied from the column in the database to a server that has the single purpose of decrypting the cyphertext just prior to sending it to the credit card processor through a leased line connected directly to that server. The PAN is decrypted at the last possible moment.
Or is it? It would be better if the credit card processor would decrypt the PAN just prior to posting the charge on their system. That would be ideal, but in 2015… in the era of vintage 1928 mag stripes still on our credit cards, the credit card processors are accepting all kinds of risk paid for by their 1.5-4% fees. The processors simply will not undertake the extra effort to do decryption, manage keys, etc. They receive credit cards that are only encrypted via TLS or SSL. TLS/SSL encryption is to encrypt data ‘in transit’. It does not encrypt ‘data at rest’ like End-to-End encryption does.
Note in our enterprise example, with the given situation, data is decrypted at the last possible moment. It’s not possible to decrypt on the credit card processor’s system, so it’s decrypted on a dedicated server, just prior to sending to the processor.
End-to-End encryption is considered the best encryption because the data is encrypted while in transit, and at rest, from the moment it is sent, to the moment it is received. It provides better protection than all the other encryption methods including the ‘at rest’ database specific methods (ie, columnar encryption), ‘in transit’ network specific methods (ie, TLS/SSL), etc.
