Dangerous Assumptions About Encryption Technologies
by Greg Parker, Raketu
If there’s one thing we know for sure, it’s that no one wants to have their privacy intruded. Still, it’s all too rife: from Edward Snowden outing NSA communication surveillance and Jennifer Lawrence’s iCloud photos getting hacked, to the well-publicized “Snappening” and WhatsApp hacks. Even talk show host John Oliver’s recent YouTube video took the topic to the masses, showcasing both how little people actually know about the topic of encryption while still proving that they want their private personal data kept private. The answer, claim web and mobile app experts, is encryption technology which, at its most fundamental level, takes data and converts it into an undecipherable bunch of characters, looking nothing like its original form. Then, decryption technology converts it back to the original data.
The problem is that laypeople presume the term “encrypted” is a panacea for privacy. This is just not so. There are several assumptions that need disproving so that we can all be more educated about our choices around privacy.
1. Myth: All encryption is the same
Encryption conversion usually uses a key, known as the encryption key, and puts the original data through an encryption algorithm using the encryption key to create the undecipherable mumbo jumbo. Thus, the encryption is dependent on two factors: 1) the encryption key and 2) the encryption algorithm. Ideally, encryption bit lengths are not only matched, but also higher in length. It is the combination of the encryption key and the encryption algorithm(s) that differentiate one encryption from another however most encryption is limited by one or the other. In most cases it is either 128bit or 256bit. Https/tls/ssl, for example, uses 256bit encryption on any bit length of key, which means its highest level of encryption is 256bit no matter what the key length is. Bottom line: the higher the encryption bit length, the harder it is to break.
RakEM uses encryption lengths of up to 4096 bit, using the maximum possible for a given task and conditions.
2. Myth: End to end encryption means messages cannot be hacked
Most messaging apps that claim end-to-end encryption actually mean the following: a user composes a message, hits send, the messenger takes that message and sends it to their server via https while not encrypting the content, and it is stored on their server, unencrypted. When the intended recipient retrieves the message, it is taken from their servers (unencrypted) and sent to the recipient through https. The problem here is that at no time is the content encrypted, and https on its own is not secure. Even if the content were encrypted, it still goes to their servers where it is stored in a decryptable (i.e. insecure) manner.
With RakEM, we encrypt the content, and the encrypted content is then sent, directly from device to device (ie. no servers). This is true end-to-end encryption.
3. Myth: Open source encryption is safer
While open source allows any third party to validate encryption algorithms, it does not infer it is better encryption. In fact, it gives unwelcome parties (even hackers) more information about how the algorithms work and how keys are exchanged which could lead to exposing holes or hacks into the code, such as with the recent OpenSSL Heartbleed bug. Fortunately, the open source community caught this. Closed source, on the other hand, does not suffer from this vulnerability, but it does rely on the creator proactively testing and looking for security vulnerabilities, including allowing third parties to audit. Encryption is not necessarily better in one over the other.
At RakEM, we use our patent pending self-mutating encryption algorithm and exchange. This allows the highest levels of encryption on a transaction by transaction basis (ie. each message looks different even if the content is the same). We are looking into the idea of open sourcing all or portions of our code and algorithms.
4. Myth: Transport encryption through ssl/https/tls is sufficient
Ssl/https/tls only encrypts data in motion but it does not cover data at rest. As data is written to disk or stored in databases, whether it’s stored for one minute or several years, it is not encrypted. SSL only encrypts at a level of 256 bit.
RakEM encrypts the messages “at rest” and during the entire journey from source to destination.
5. Myth: Once encrypted, data is protected from third parties
This is simply inaccurate. For example, https/ssl/tls at the highest level of 256 bit encryption has been shown to be unencrypted by third parties such as governments and spy agencies, not to mention hackers, who are able to intercept the streams. If a hacker or third party gets ahold of a private key in a public/private key encryption method, all intercepted data could be decrypted without the user knowing. In addition, if a hacker or third party uses what is called a “brute force” style of attack on encrypted data, their success will be directly dependent on the encryption key length and algorithm strength – in this case, the higher the better as 256 bit encryption has been known to be penetrable given enough computing power and time.
RakEM uses encryption lengths of up to 4096 bit, using the maximum possible for a given task and conditions.
6. Myth: Higher encryption is always better encryption
While in general this is true - for example, 2048 bit encryption key length is more difficult to crack than 256 bit encryption key length - in the case of https/tls/ssl for example, using a 2048 bit transport key has little affect since its transport encryption level is set at 256 bits and no higher. In addition, the content in this scenario is not encrypted “at rest”.
RakEM encrypts the messages “at rest” and during the entire journey from source to destination. RakEM uses encryption lengths of up to 4096 bit, using the maximum possible for a given task and conditions.
7. Truth: Encryption is better than no encryption
It probably doesn’t need to be said, but some encryption is, generally, better than having no encryption. Problem is when the level of encryption is low (for example: 128bit), the encrypted information can be relatively easily decrypted while the user believes it to be secure. So while some encryption is better than none, users should be aware that low level encryption is not secure.
At RakEM, we use the highest levels of self-mutating encryption available.
8. Truth: Device to device direct transmission is more secure
When data moves directly from one device to another device, without the use of servers or relays, it makes it much, much more difficult for hackers to “find” the transmission in the first place. When data moves from device to server to device, hackers can simply “listen” in on or near to the server to intercept conversations – in other words, they know where to look. Add a high level of encryption to the content on a device to device direct transmission, and you have even greater levels of security.
At RakEM, we use device to device direct transmission.
9. Truth: Self-mutating or transactional based encryption is more secure
Imagine sending a text message that says “hi” to a friend. Typical encryption algorithms will turn “hi” into some long string of characters, for example “234bdue4454bshl…”. And, when you send “hi” again, it will again look like “234bdue4454bshl…”, over and over it looks the same. With self-mutating, or transactional based encryption, the encrypted data is different every time. So sending “hi” may look like “der654fe8fjebrj…” the first time, “32fe54dke98djr8…”, the second, “e43erk87ehrj876…”, the third, etc.. This makes it very, very difficult for a hacker to determine the key and decrypt the content. Even if the hacker did determine the key on a given transaction, it would not successfully decrypt the next “hi” since the key has changed. Add high levels of encryption lengths, and it makes it next to impossible to break.
At RakEM, we use the highest levels of self-mutating encryption available.
So what’s the key takeaway here? If you want to ensure your communications are truly secure and private, “read the fine print” when it comes to encryption claims and understand that not all encryption are created equal.
