Google announced that they may (the code is not officially supported yet) support PGP Mail in GMail. This might seem like an unabashed win for user privacy since it would make it impossible for Google to read their user’s mail. This article points out a number of problems with Google’s actions (I still think Google should be commended for doing this work) but I’d like to focus on a different issue than covered in the article - why digital signatures are a bad idea in general for social networking/email and how Thali deals with this problem.
That will go on your permanent record!
Imagine, for a moment, what your world would look like if every time you had a conversation with someone a permanent record was made of the conversation. The record would be fully authenticated and suitable for use in the court of public opinion and/or law.
In this world our everyday lives, our conversations, our exchanges, with anyone about anything become little permanent records that follow us around forever.
This is exactly the world we create with technologies like S/MIME and PGP Mail. Or, more generally, the world we create when we use digital signatures. A digital signature is intended to be an authenticator, a way for someone other than us to prove that we did/said something. When we use digital signatures for momentous things that should be on the public record, like mortgage documents perhaps, then they serve a good purpose. But with PGP Mail we suddenly sign... well... everything. It’s like having a notary public walking behind you all day long stamping every statement, note, mail, etc. as provably and irrevocably yours.
I don’t think we want such records to exist. I think we want a much more ephemeral world where the bulk of what we do just quietly vanishes into the ether leaving as little of a trail as possible. The open source experiment I’ve spent the last year or so working on (and why I haven’t been blogging much, I’ve been insanely busy) is called Thali and we are trying to build that ephemeral world.
Making the record less permanent
In Thali all communications are point to point. The email you write on your phone will be sent directly to, for example, your friend’s PC (or tablet or phone or whatever they happen to use). Those point to point communications use TLS to secure them (in addition to Tor hidden services). TLS is great because after the key exchange (which uses public keys), everything else is exchanged using a symmetric key. I’ll skip the gory technical details and just say that in a symmetric key exchange both sides of the conversation have the same key. This makes it impossible to know who said what since either side of the exchange could have encrypted it, they both share the identical key.
TLS is also not designed to be stored so it’s inherently ephemeral. Even if it is stored by some third party Thali will enforce using something called ephemeral key exchange which just means that each party destroys one of the public keys used during the exchange and doesn’t store the symmetric key. This means that once the session ends, even if a full record of the encrypted conversation existed, unless the person holding the record can crack the keys there is no way to read what happened because neither participant in the conversation has the right crypto material to open it up.
What this means is that if I sent you an email then after the TCP connection is used to transfer the mail from my device to your device what you are left with is the moral equivalent of a text file. If someone comes along later there is really no way to prove who wrote that document. Your device knows how it got it and will internally record information about how authentic it is. But unlike a digital signature none of this is encrypted or proved in a way that ties to the sender.
Since Thali is walking in the steps of the work I did before on Paeony I expect that eventually Thali will implement requirement AAI from Paeony. This effectively says that users can (usually automatically) put policy into their communications indicating how long they want the other party to keep a copy of what was sent. For you techno geeks, think of this as a caching policy.
The idea is that when you send a message to your friends their Thali systems will automatically discard information when you have asked them to. This is all handled automatically. And no, the discard request is not DRM. Nor is it intended to be secure. Rather it is a externalization of the kind of implicit social rules that makes society possible. It says that well behaved friends will be well behaved and helps them (automatically) understand what that means. Jerks will always be jerks and no technology will fix that. So if someone overrides the policy then that is that. It’s like telling your friend a secret, having them swear not to share and then having them share the secret anyway. Sorry, that’s the risk you run when you have relationships. Anyone who tells you their magical technical pixie dust will fix this is lying or ignorant or both.
No, this won’t keep you out of jail
Good technology can’t fix bad laws. So don’t expect avoiding digital signatures to keep you out of jail if you don’t want to held responsible for something you said or something someone pretending to be you said. I’ve discussed this before, but the legal burden of proof is very different than what a computer scientist might think it is. I’ve been told about convictions in court based on text logs that anyone could have trivially edited. One suspects that if a court gets a hold of one of your friends devices and sees emails with your name on it, that will be just fine thank you as evidence. It doesn’t matter that they aren’t signed and could be easily forged.
So the point of the Thali design isn’t to enable someone to have a brilliant moment in court “Ah, but members of the jury you can’t convict because our magical bumbly do means it’s impossible to scoobi doo the evidence!” Um... no.
Thali’s avoidance of digital signatures is really about designing a system to use the right tool for the right problem. If you aren’t trying to make a ’forever’ statement then don’t use a ’forever’ tool like digital signatures. If you want a conversation to be private and ephemeral then share it with the fewest people possible and don’t sign it.
Appendix
A Isn’t Thali’s use of TLS just a variant of off the record messaging?
Basically, yes. This isn’t really Thali though. This is just how modern TLS works. Once ephemeral keying was added as a standard cipher suite this effectively made TLS into a type of off the record messaging when that cipher suite is used.
B Why can’t we use disposable digital signatures?
This idea comes from off the record messaging. My search skills have failed me as I can’t find a good link to really describe this variant on off the record messaging but I know I didn’t come up with it. The approach is:
- Create your root key pair that everyone trusts, we’ll call this KeyR
- Create a sacrificial key pair that we’ll call KeyS
- Create a cert for KeyS signed by KeyR that sets KeyS’s expiration date 1 day into the future (or whatever time makes sense for the scenario)
- Before KeyS expires use it to sign messages
- Once the cert expires publish the private key for KeyS in some well known location
The idea is that until KeyS expires anyone who receives a message signed with KeyS can see that it is validated by KeyR and since KeyS isn’t expired, will trust it. Once KeyS expires, it won’t be trusted by anyone.
Now imagine that some time in the future somebody shows up with a message signed by KeyS and says “This had to come from you since KeyS was trusted by KeyR and you are KeyR!” You can then respond - “ah, but I actually published the private key for KeyS so anyone could have created that message! You can’t prove it came from me!”
The point is that before the key expires the private key for KeyS is a secret and so receivers of messages can trust they came from you. After the expiration date the private key for KeyS will be published so anyone can create valid KeyS messages.
This is sometimes known as plausibly deniable encryption.
I’m not a big fan of this approach for multiple reasons.
First, it fails the minute any kind of reasonably trustworthy escrow/time stamp service exists. You just have to show that the message existed before the expiration date and that’s it.
Second, it’s just way too cute. With security, less is more. So simple systems (create connection, close connection, discard keys) are generally better than fancier ones (create cert chain, use keys, publish keys forever and ever and ever and ever).
Third, having a path in my code that intentionally publishes private keys seriously freaks me out. I don’t want code that can do that anywhere near my platforms/applications. It’s just begging to be a vector for some really awful security holes.
But still, it’s good to have many tools in the security arsenal and this one is at least internally consistent, so who knows, it might be useful.
“This is exactly the world we create with technologies like S/MIME and PGP Mail. Or, more generally, the world we create when we use digital signatures.”
This post seems to imply that signing and encryption are joined at the hip. I haven’t used PGP Mail in a really long time, and never routinely, but http://docs.kde.org/stable/en/kdepim/kmail/pgp.html suggests that, as I believe is the case in S/MIME systems I’ve used (it’s been a while), you can sign only, sign and encrypt, or encrypt only.
If I encrypt only, to your public key, but don’t sign (using my private key and attaching a certificate with my public key) then I think (always ready to be shown I’m wrong!) that I’m not binding my identity to the message. Is that not an option, or not the default anyway, in the PGP systems you’re thinking of?
For some years I routinely with use S/MIME (in Thunderbird and Outlook) to sign but not encrypt. I liked the idea of recipients expecting mail from me to be authenticated by a cert I gave them, and knowing to distrust other mail “from me.” Of course it was quixotic, basically I was just sending attachments that people did not understand and were annoyed by :-)
It’s always a struggle when writing articles like this to decide how far down to jump in the details. You are absolutely correct though. If you encrypt (with the destination key) but don’t sign then you get privacy for your message without binding yourself to the message. But most email crypto systems don’t work this way and for good reason – the whole point of crypto is knowing who you are talking to! So usually they want a digital signature too in order to be able to prove that the message came from a known/trusted source. Thali handles this by validating the transport but not the message. But that is obviously not workable for SMTP since it is a store and forward protocol and nobody wants to try and have transitive trust through a bunch of hops.