Modern Crypto

I don't use Signal mostly because nobody I know uses it, even though I know they have it installed. By pure usage statistics the winner would be WhatsApp. I also use Wire.

In terms of issues with each of these, Wire has occasional bugs and hiccups (UX wise) and would be unsuitable for large groups exchanging messages (every device implies an entirely new ratchet, users own multiple devices, and all Wire group chats are client-fan-out, meaning pairwise ratchets with all members. Users with more than one device, even if they communicate one-on-one, are effectively in a group session). However the group message problem implies trade-offs and doesn't have an easy solution, so this shouldn't be seen as game-ending criticism (there's an ongoing effort involving people from all three messengers to figure out group messaging in a safe and scalable way, called Message Layer Security). WhatsApp is much more feature stable, but compromises on client-fan-out to make group messaging simpler. I think Signal also does client fan-out. I think Signal were also a bit dismissive of the low order point issue in their protocol (https://research.kudelskisecurity.com/2017/04/25/should-ecdh-keys-be-validated/), but it's arguable whether this is an issue at all their instantiation of DH (https://moderncrypto.org/mail-archive/curves/2017/000896.html). So in terms of cryptography, all three are state-of-the-art.

I haven't really used Threema, but for completeness I had a brief look at their crypto…

Hi, I wrote about it before here:

https://moderncrypto.org/mail-archive/messaging/2014/000780.html

> most of your discussion of what to do is to increase the cost of sending lots of email.

I don't think I've ever proposed increasing the cost of sending lots of mail? Or not that I recall! I've definitely discussed increasing the cost of sending lots of unwanted mail, but that's not the same thing.

> No one credible is trying to do this: every complete and in-depth model for this that I have heard involves variable pricing, decided by the receiver per-sender, and entirely solves these use cases.

Variable pricing doesn't solve the issue because a key part of email is the ability to receive emails from strangers who haven't contacted you before. This can also be the case for bulk mailers, e.g. if you write down your email address with pen and paper for your local school, who then emails every parent. How do you price that? And is this "price" measured in abstract units people have no intuition for, like CPU cycles, because it's surely not in dollars.

So I've never seen a workable proposal for introducing pricing or charging into email.

> maybe those solutions don't work, but you have to argue that.

Jameson only mentions hashcash in passing, he's mostly writing about how email was better when it was more decentralised, before the coming of big providers. Which is a bit odd to me because in the early days of the internet the only people with email accounts were those…

What my blog actually said about that was:

"I’ve had some experts tell me they thought the security level was 2^80 operations (very weak), while others (including Zooko himself) thought it was [more like 2^96](https://moderncrypto.org/mail-archive/curves/2016/000742.html). I’m not sure which figure is right, but the fact that there’s disagreement is a bad sign."

I made it very clear that it is an unsubstantiated figure, and linked to Zooko's analysis. To both yourself and the person you're replying too, please don't put words in my mouth.

> We provided participants with a reproducibly built and stripped down version of Alpine Linux, employed grsec, wrote all of our crypto software in pure Rust, etc. All of our software is reproducibly built, hashed and signed. There is nothing (software-wise) that cannot be caught in post-hoc review. All of it is open-source: https://github.com/zcash/mpc

I agree. But that's not what I said; what I said is that post-hoc review hasn't been done, even a year after the fact.

Hi, I'm the author of this document and principal developer of the project. This is a somewhat detailed design overview for a proposed alternative to the PGP keyserver system that I'm building and I didn't really write it for a general audience to avoid cluttering it up with too much background information.

Sometime soon we're going to improve the website with a friendlier high-level description of the goals of the project and the problems that it solves. For now, I apologize that this rather dense document is the only information available.

It might be easier to understand what I'm trying to achieve by reading a post I made yesterday to the modern crypto mailing list which summarized the important features of Nyms:

https://moderncrypto.org/mail-archive/messaging/2014/000602.html

That's a common problem when using OTR with the same account in a multi-device environment. It is fixed by the introduction of instance tags in libotr 4.x [0]. You should check the versions of libotr used by all your clients - if they are all libotr 4.0+, you shouldn't have these problems.

[0] https://otr.cypherpunks.ca/UPGRADING-libotr-4.1.0.txt

A simple workaround is to use a different account for each device (e.g. me@jabber.com, me+mobile@jabber.com).

TextSecure's developers recognize that a good multi-device experience is essential to provide a comparable experience to other messaging apps. Their approach is different from OTR's, and is described here [0].

[0] https://moderncrypto.org/mail-archive/messaging/2014/001022.html

Boxbe is an interesting service, thanks. Maybe this 'permission-based' was never a standard because spam didn't exist back then and, later when it did exist, didn't play well with the idea of mailing lists. In the latter context it's funny how this search term is SEO'd to return marketing services!

Having just read a former google abuse team member's take on end to end encryption and anti-spam[1], this topic now looks a lot more complex. Regarding IM's, he mentions how spam-free WhatsApp is and argues that spam is a lot easier to fight when you have central control because you can change anything at any time at any point (client or server).

[1] Mike Hearn, https://moderncrypto.org/mail-archive/messaging/2014/000780.html