Related: "New Visual Studio 2013 Security Feature: ASP.NET Identity"
If you haven't been paying attention to the news recently, Adobe's recent foray into the limelight for losing 150 million usernames and encrypted passwords is shaping up to be a failure of truly epic proportions. One reason this security breach is likely going to be one of the largest in history is that Adobe, instead of correctly one-way hashing their passwords, further went on to spectacularly fail to even encrypt these passwords correctly. Consequently with Adobe's horrible misuse of encryption (both in terms of application and execution) fresh in the news, I thought it'd be worthwhile to review encryption in terms of what it is, where it currently stands, and why whatever you're currently using might not actually be up to par.
Encryption is Ubiquitous
Encryption is simply everywhere. It's the lubricant of modern commerce, communication, and computing. I recently touched upon how it's part and parcel to enabling obvious things such as browser security and different types of secured communications. However, that really only scratches the surface of how we, as developers, depend on encryption. Obviously, we also use encryption to secure sensitive information (at rest or in transit), but it's also worth noting that encryption is key to building much of the software we build -- even when encryption isn't, seemingly, part of what we're building. For example, build servers, version/source control systems, and even the signatures we use to verify the authenticity of many coding components or license much of the software we build all uses encryption in one way or another to help secure and protect several different tools we use to build applications.
Stated more simply: we take a lot for granted as developers because many things that we build wouldn't work as it does without encryption. But, by the same token, if encryption is so essential to what we do, then it also stands to reason that any time that we're protecting data or systems, we need to 'future proof' those systems against advances and potential attack vectors. Unfortunately, this is worth pointing out that much of the encryption infrastructure that we use today is living, effectively, on borrowed time.
Asymmetric Encryption and a Coming Cryptopocalypse?
Much of the genius that we (or at least I) take for granted in terms of our modern encryption is rooted in the reality that asymmetric encryption is based on the fact that multiplication is easy, while factoring is harder. Due to some fascinating mathematical properties and the nature of our universe (that still strike me a bit as being almost like voodoo), it's actually possible to make it such that the magnitude of difference in effort between multiplication and factoring is, effectively, a moot point when put under the right constraints (primarily by setting a ‘top-level' bound of prime numbers and wrapping).
Related: "OWASP Top 10 Project: Security Vulnerabilities for ASP.NET"
If that sounds entirely too simplistic or even insane, then take a few minutes and go check out a great article that I bumped into the other day that actually explains current approaches and techniques to asymmetric encryption in much better detail as a precursor to explaining why what we're currently using is flawed. In overly-simplified terms, a primary problem with many existing cryptographic systems today is that the protection generated on lower-powered mobile devices can't quite stack up to the kinds of decryption capabilities that are increasingly becoming available to hackers running high-end servers and massively-parallel GPU enabled workstations -- all thanks, strangely enough, to multiplication and factoring requiring such entirely different amounts of effort. This might sound like I'm contradicting myself unless you go ahead and read the link I just provided about asymmetric encryption.
ECC: The Future of Encryption?
If you read that article that I linked to for its introduction to current approaches for encryption, then you'll see that it's primarily covering existing techniques and their weaknesses as part of an introduction to Elliptic Curve Cryptography (ECC), which provides exponential degrees of cryptographic protection without correspondingly huge increases in key-sizes (a true paradigm shift or revolution). Of course, although ECC looks pretty amazing and powerful and is enjoying gradual, mainstream, adoption it's not without some warts (such as the fact that numerous patents for ECC are owned and enforced by Blackberry along with some ugly implementation problems) or worries (such as the recent revelation that the NSA hijacked a commonly-used Random Bit Generator (RBG) used for ECC to insert their own back-door). But, by and large, ECC looks like it's gradually becoming the wave of the future because of its ability to generate substantially more entropy with comparatively smaller keys.
As such, I've started doing a tiny bit of my own research into how hard ECC would be to use in some of my own projects and have just barely bumped into BouncyCastle, which provides ECC libraries for C# and Java. I've yet to even crack open the code or look at anything more than some cursory examples, but thought I'd pass along the link for anyone that made it this far.
