I'm not really positioning TextSecure as a secure mail solution, but this article says that the TextSecure protocol can't support asynchronous operations or federated namespaces. To clarify, that's incorrect, the TextSecure protocol was actually designed from the ground up for asynchronous communication, and is designed to support a federated namespace: https://whispersystems.org/blog/asynchronous-security/
That leaves these points for PGP:
> It’s been around for a long time, so it’s cryptographically well understood.
Yes, but it's cryptographically well understood not to provide the properties we need.
> There are a variety of implementations and there is a small but vibrant and highly committed developer community.
> A small but active and committed user community.
Small can't be emphasized enough, and this is the most important part to me. I think people have a tendency to look at PGP and conclude that while it might be painful, we have to put up with it for backwards compatibility. The truth is that it's a protocol with few contemporary redeeming qualities, and an active user base of ~50k. So why bother with backwards compatibility?
> Yes, but it's cryptographically well understood not to provide the properties we need.
If you're talking about perfect forward secrecy, surely that's fundamentally impossible for a protocol that is both asynchronous and decentralized? If one party can only send a single async message to another, then that message necessarily must be decryptable by that second party using only what that second party knows, and you lose PFS. PFS only works for synchronous communications where both parties can use a key exchange protocol, or centralized communications where an asynchronous message can be implemented as a synchronous message to a central authority. No?
> With the initial key exchange out of the way, both parties can then continue communicating with an OTR-style protocol as usual. Since the server never hands out the same prekey twice (and the client would never accept the same prekey twice), we are able to provide forward secrecy in a fully asynchronous environment.
So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?
This isn't really asynchronous in the sense that email is (stop-forwards-stop-forward). Nor does it appear to work for writing and encrypting an sms while on an air-plane (the message will only be encrypted when the pre-key can be retrieved).
It doesn't seem quite fair to claim (or rather imply) that the scheme does for email what pgp does.
It also carries more state around (on the "server" and on the "client") so it's not decentralized. It might be closer to pgp than classic otr, but it's not really a replacement for pgp as far as I can tell.
> (the message will only be encrypted when the pre-key can be retrieved).
The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client.
> So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?
You encrypt it on your laptop, transfer the encrypted blob to your online machine and send the blob through it. All state is managed by your laptop, intermediary machines are just forwarding the message (which is merely an opaque blob at this point, possibly with a "destination" to ease routing to the recipient(s)).
> Nor does it appear to work for writing and encrypting an sms while on an air-plane
From a user pov, there is no difference between:
- I type the message and hit send, the message is encrypted now and sent when I have connectivity
- I type the message and hit send, the message is encrypted and sent when I have connectivity
The problem here will not be technical but purely UX (the software has to allow deferring encryption and sending when resources are available)
> It also carries more state around (on the "server" and on the "client") so it's not decentralized.
The little state there is on the server really doesn't sound centralized to me in that it is really simple (the server must be able to store a given list of blobs sent by the client, and the server must not send twice the same blob, ever) and a client can choose any server (there is no concept of "registration", but the client has to trust the server it will not misbehave).
The state on the client is really client-specific, it wouldn't make sense to share a client's ratchet state: as a comparison you wouldn't share the current bucket list of your DHT client with other machines because it doesn't make sense, you would rebuild it from scratch on another machine. Effectively this means every device of yours is considered another independent "peer".
I think it's important at this point to say that this mechanism is the Axolotl ratchet (more details here: https://github.com/trevp/axolotl/wiki). It only describes how to exchange encrypted messages between two DH keys, asynchronously, and with forward secrecy. It doesn't care about :
- what is the relationship between DH keys ("should I encrypt to 2 DH keys because they belong to the same user ?")
- how do get someone's key, and is it the good one (the key distribution management)
- how can I have a coherent message history between my phone and my computer
These are all real problems that TextSecure aims to solve, but they're a whole another thing.
> The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client.
Well, no. It's needed when you client has never talked to someone. If you have a pad, a phone and a laptop, they all need a pre-key to talk to the same person. If the person's server is down, the system breaks down (you can't have just anyone mirror the pre-keys).
> From a user pov, there is no difference between:
>
> - I type the message and hit send, the message is encrypted now and sent when I have connectivity
>
> - I type the message and hit send, the message is encrypted and sent when I have connectivity
Perhaps not. But there's a difference between being alerted that you can't reach the recipient securely before you type the message, and getting that message (no pre-key available) after you've taken the time to write the message.
Not to mention that hopefully the device has FDE, so there aren't any plain-text messages around for when you go through customs, or when someone steals your phone etc. But I'll concede that device security is probably outside the realm of what a message system should deal with.
Don't get me wrong, I welcome improvements like this -- I just don't think it's comparable to pgp (which is both good and bad).
So yeah, you're relying on a central authority to maintain the prekeys and only give out each one once. The within-session ratchet is cool but I'm not sure if it's relevant to an async use case like email where messages can be sent months apart (would you ever even use a session for more than 1 message?) and the user /wants/ to retain the ability to read their old messages. Likewise the non-repudiation aspect of PGP is by design: it's meant for a use case where you want to "get something in writing", it's supposed to behave like a signature on a letter. (And by the same token it's very much an inappropriate protocol for e.g. IMs, which is why even big fans of GPG will use OTR or some such for those instead).
There's maybe a case for a protocol that offers both (though in practice I've just seen people sign their OTR key fingerprints with their PGP key), but that goes against the simplicity that you're emphasising.
It is not fundamentally impossible. It has been shown [1] that forward-secure public-key encryption can be done without the key size blowing up with the expected number of encrypted messages, though it's not very practical. The trivial case of §3.2, in which the key is simply a tuple of N keys which are erased as messages are encrypted/decrypted, seems similar to what TextSecure does.
He doesn't have one. Sometimes I wonder how difficult would be to sneak a sabouteur into the crypto community, who advocated for ditching proven and safe crypto tools, wanted his solutions on top of centralized servers owned by others, opposed distribution of signed binaries in FOSS markets, recommended the people to use stock OSs with binary and who-knows-what google libs inside, instead of installing the free counterparts, etc..
Is like people have forgotten that they should trust only the algorithms and the implementations, not the persona behind them. And that persona, should be the first saying "don't trust me! trust my algorithms!".
The 50k number comes from the number of people who can reach each other through the web of trust.
If you take every key uploaded to the key servers ever, then it's more like 4 million. However most of those aren't active.
TextSecure, in contrast, has vastly more users than PGP has ever had, despite being a lot newer.
Sometimes I wonder how difficult would be to sneak a sabouteur into the crypto community, who advocated for ditching proven and safe crypto tools
Sometimes I wonder if the best way to sabotage the crypto community would be to fill it with people aggressively advocating for obsolete technologies that have zero chance of any meaningful impact :)
Moxie is unusual in the strong crypto space, in that he is willing to make pragmatic engineering choices in order to ship a working product. That is why he and his team have had a lot more impact than most others have.
Having it installed doesn't mean using it, like you said, for the PGP keys being generated but not necessarily in use.
On textsecure usage
In my experience, very very few people actually sign keys, and few people upload them on keyservers.
Also, I know very very few people who use textsecure. I used it for a few month, trying to get others to talk to me with it and gave up. And I'm in the bay area working with IT people, most of my friends are IT people mind you, we're exactly the people who try that stuff all the time.
It doesn't mean its bad tech or a bad attempt at all, heck, I would LOVE for it to catch up. But I seriously doubt it has 4 millions active users or more.
On PGP usage
From a key server perspective there are still a large number of keys being downloaded, refreshed and updated daily.
Let's look at Mozilla's stats and they just seem to peer with one low traffic guy and themselves... http://gpg.mozilla.org/pks/lookup?op=stats
that's 1k new keys a day, and about 500 updated a day. We're far from the 50k claim since it would reach that in 50 days no matter what.
Of course saying there's only, say a few millions PGP users doesnt mean AT ALL the same as 50k.
On misinformation
Thus I'm calling bullshit. Purposefully misrepresenting data (large order of magnitudes, at that) is a big minus in my book. Being well-known shouldn't mean you can tell people bullshit - if anything, you have a greater responsibility when you do.
> It doesn't mean its bad tech or a bad attempt at all, heck, I would LOVE for it to catch up. But I seriously doubt it has 4 millions active users or more.
The 4 million figure was total users of GPG ever, not TextSecure. TextSecure for Android has had about 1 million installs.
However, it's also been integrated into the Cyanogen mod which added about 10 million users, and the tech has been integrated into WhatsApp, which got the underlying crypto code (though not the UI) to about 400 million+ users.
So if by "TextSecure" we mean the technology rather than the actual UI widget code, which is generic anyway, then it's in a whole other league by orders of magnitude.
You compared the total of PGP users to textsecure saying textsecure has more hence my reply on that (just clarifying)
Or least, that was my understanding of your previous comment
You're basically kinda saying there is between 11millions and 400 millions users, and, you know, i dont trust that at all and would compare it to notepad/paint being installed on windows but not actually used.
Anyway, whichever tech really catches up would be a good thing. I just dislike the manipulation of information for marketing of one tech over another for fame, money, power etc.
Specially when that means bad mouthing free and open source projects :)
That leaves these points for PGP:
> It’s been around for a long time, so it’s cryptographically well understood.
Yes, but it's cryptographically well understood not to provide the properties we need.
> There are a variety of implementations and there is a small but vibrant and highly committed developer community. > A small but active and committed user community.
Small can't be emphasized enough, and this is the most important part to me. I think people have a tendency to look at PGP and conclude that while it might be painful, we have to put up with it for backwards compatibility. The truth is that it's a protocol with few contemporary redeeming qualities, and an active user base of ~50k. So why bother with backwards compatibility?