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 Marylandcreated 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’ll 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:
https://twitter.com/embed/status/530015453452963842
But if you had access to the key, it just said “Hello there.”
Here’s a general demo of how ShadowCrypt works:
https://www.youtube.com/watch?v=MHM1mv_K_Q0
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 e-mail 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 e-mail 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 e-mail,
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
e-mails.
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.
