If you want to make sure you're sending a secure message, there's a whole slew of privacy-minded services that include encryption these days. But sometimes you just want to send something on Facebook without feeling like you're a prime candidate for digital eavesdropping. That's where ShadowCrypt comes in.
Researchers at UC Berkeley and the University of Maryland created the browser extension, which lets people exchange encrypted messages from most popular social web apps, including Gmail, Facebook, Reddit, and Twitter. It's a research tool that shows that encryption on big-name mainstream web services is possible.
ShadowCrypt is compatible with over 14 popular web services. You install it on Chrome, and then you can generate encryption keys for any of its compatible services. Then you share the encryption key with the person the message is intended for. This means they will be able to see what you've sent, but everyone else (including the site operator) will see digital gibberish.
I tested it out on Twitter and it was easy enough to use, just toggle the extension on and type what you want. There's a default key that anyone using ShadowEncrypt has access to, so you have to get a new one if you want yours to be properly locked-down (I just used the default here because I didn't actually have anything top-secret to tweet).
This is what my tweet looked like to the outside world:
— Kate Knibbs (@KateKnibbs) November 5, 2014
But if you had access to the key, it just said "Hello there."
Here's a general demo of how ShadowCrypt works:
For now this is just a research project, but it's proving an important point: it's not that hard for any big service to provide encryption. Google and Apple are already making strides to encrypt data, but other services (like Twitter and Facebook) are lagging behind.
ShadowCrypt's methods didn't wrinkle out all of the usability problems that crop up when you integrate encryption into pre-existing programs. Some of the programs didn't work well with ShadowCrypt, like Google Spreadsheets. And even those that did work weren't perfect. For instance, if you tweet with it, you're limited to a paltry 45 characters since the encryption takes up the rest of the space.
This is just a Band-Aid solution that draws attention to how important it is for services like Twitter to come up with native encryption options. But it's a pretty nifty Band-Aid.
Update: I asked Seth David Schoen, a senior staff technologist at the Electronic Frontier Foundation, what he thought about ShadowCrypt. He called it "important and thoughtful research" but elaborated on some of his concerns. His comments are insightful and echoed some of the valid critiques commenters have pointed out, so I'm going to reproduce them here:
If you and I were using some kind of web application that doesn't provide crypto tools, and we both had ShadowCrypt, how do we safely exchange keys so that you can decrypt the data I send you and vice versa?
You can imagine that we could just email keys to one another. That would be good for hiding the content from the web site that we're using, but anyone who could read our email would then be able to figure out how to read the ShadowCrypt encrypted data. So we wouldn't get privacy against anyone and everyone, we'd just get privacy against the particular web site that we're communicating through. For example, if we're encrypting Twitter DMs and exchanging keys via Gmail email, we've protected our messages pretty well from Twitter alone, but not from Twitter-working-together-with-Gmail.
The current version doesn't really solve this problem in a definitive way (and many existing tools, facing the same problems, have settled on solutions that all have fairly significant drawbacks). The researchers say in section 5 that they're still looking into it and still exploring potential solutions.
The other difficulty is that this tool tries to retrofit secure communication into channels and applications that weren't designed to be secure or private. As a result, it provides for occasional secure communication when users actively choose to go secure, with a default of non-private communications. For example, users might use ShadowCrypt to choose to encrypt the most sensitive 5% or 10% of their Twitter direct messages, or the most sensitive 15% of their Gmail emails.
The protection they get in that situation is great -- and users should definitively have that ability! -- but the need to make an extra decision, maybe a conscious decision, to protect particular messages may lead most users to a place where they're still not encrypting most of their communications most of the time. That's certainly been the case for other systems, like PGP, that default to unencrypted communications and make users choose to apply the protection case-by-case.