The developers of the free & hugely popular encryption program dropped a bombshell at the end of May when they abruptly abandoned the project. The top of their website was emblazoned with the following message in red: "WARNING: Using our Software is not secure as it may contain unfixed security issues." It also said development of our software had ended after Microsoft terminated support for Windows XP and recommended that users of Windows 8, 7 and Vista migrate to Microsoft's BitLocker disk encryption utility.
The site provides instructions for migrating to BitLocker. The only version of our Software that is available for download on the site, version x.x, is only good for decrypting existing data to carry out the migration process.
Why was this hugely popular Encryption Software Abandoned?
A code audit that is being carried out, using $60,000 that was raised on Indiegogo and Fund fill revealed one or more serious security flaws that have not yet been revealed. (An initial report into just the boot loader and Windows kernel driver of the program identified 11 vulnerabilities, said the quality of the source code was bad, and concluded that "overall, the source code for both the boot loader and the Windows kernel driver did not meet expected standards for secure code.
Encryption! Should we?
There are technologies available in the market which can sense and decrypt the encrypted data or traffic and these tools are in the reach of common IT savvy employees or administrators. Why it works even if we have encryption. In common with a very large proportion of HTTP-over-SSL webservers, is using RSA to exchange the symmetric session key that will be used by the encryption algorithm (RC4 in this case). The server can of course decrypt the pre master secret passed to it by the client (by using the server’s private key), and subsequently both the client and the server derive the master secret from it – this is the symmetric key that both parties will use with RC4 to encrypt the session. But the server isn’t the only one with the private key that corresponds to the public key in the server’s certificate – certain SSL dissector software has it as well. This means it is able to decrypt the pre master secret on its way from the client to the server, and thereafter derive the master secret needed to decrypt the traffic.
How to Prevent Decryption?
There are at least two methods to approach this:
- Method one – Protect the server’s private key for sure
- Method two – Don’t use commonly used RSA for key exchange
Protection of one’s private key is at the core of any system using asymmetric keys. If your private key is compromised, the attacker can either masquerade as you or they can attempt to carry out decryption as outlined above. Keys stored in separate files like the ones above are particularly vulnerable to theft if access permissions are not set strictly enough, or if some other vulnerability allows access. Certain operating systems like Windows and Cisco’s IOS will try to protect the keys on your behalf by marking them as “non-exportable”. This is meant to mean that the OS won’t divulge the private key to anyone under any circumstances, but clearly there comes a point where some software running on the box has to access the key in order to use it. This simple fact can sometimes be exploited to export non-exportable keys.
Method two – Don’t use commonly used RSA for key exchange
As we’ve seen, the RSA key exchange is susceptible to interception if one is fortunate enough to have the server’s private key. By using a flavor of Diffie-Hellman for key exchange instead, we can rule out any chance of an attacker feasibly decrypting our SSL traffic even if they are in possession of the server’s private key. A D-H key exchange is by design resistant to eavesdropping, although can be susceptible to a man-in-the-middle attack unless both parties identify themselves with certificates. It’s also, as we’ve seen, not universally supported by common SSL clients. But at least it rules out the possibility of some wise guy with possession of easily available SSL dissector tools sticking his antennas where they’re not wanted!
Yes, we should think of encryption as it provides us a mechanism to protect our sensitive data when it is routed through Public channels. Please keep in mind, it is not the Encryption software which will protect you but it’s the Algorithm used in the Encryption software which can show wonders.
.png)
Comments