| HN Mirror

I'm not sure what this is in response to, actually. I'm not expressing any particular opinion about cryptography. I have no opinions and I defer to experts. One thing that I have heard experts say is that we should be very hesitant to use new protocols and software in areas in which a maximum of security is needed.

So I have no opinion of Wormhole, other than to say that (1) it is new, and experts I have listened to in the past say to be wary of new approaches, and (2) it (according to its own documentation) has some rather extreme limitations that make it arguably not a good fit as a general purpose solution to encrypted file transfer.

> My thoughts about Signal and Wire are that I did a good job of relating in the post you're talking about what I think about Signal and Wire.

As I don't think I have referred to any post by you, I don't know what you think about those solutions. If you are referring to the Latacora article (I think you wrote it, but I'm not sure because it doesn't specify its authors), it says (IMO) very little about the merits of Signal and Wire compared to other systems, and nothing at all about the specific criticisms I made in my comment you originally replied to.

What experts are you listening to? Are they telling you to use PGP in 2019?

Why do you keep nitpicking tiny aspects of what I'm trying to say? GPG sucks. Everyone agrees it sucks. The consensus of experts is that you should avoid it where possible. I have not denied any of that.

The problem is that some experts love to suggest alternatives that have severe limitations that GPG (for all its very real faults) does not have.

For 1 to 1 encrypted chats, I would trust Signal provided that OWS having my phone number (and that of my conversation partner) was not a security risk, and that I'm not facing a nation state level adversary who could take over OWS servers and push a compromised version of the app to me via update mechanisms.

In my opinion those are serious limitations that GPG does not have. And this is an area in which we're talking about the most developed alternatives (other than signing). Other areas like encrypted file transfer and group chat are even worse.

hiq 2531 days ago

With your requirements from another post in mind:

Regarding file transfer, 'age' was mentioned in a previous thread. Problem is that it hasn't been implemented yet... https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s8...

Regarding a secure group chat messenger with your two requirements mentioned, the consensus (among experts that have given their opinion here) seems to be that there is currently no such solution (I guess some versions of Wire could fit given that they seem to have on-premise deployment: https://wire.com/en/pricing/#pro/).

Thanks for the response. That matches my understanding of the situation. I'm not familiar with age, but I hope it turns into usable tool for some of these use cases, particularly asymmetric encryption.

Wire might eventually get there, but as far as I know they still haven't implemented federation, so (though I might be wrong) even their paid deployments would be limited to some particular network on which both conversants had accounts.

Why do you want asymmetric file encryption?

* If it's to send messages to people, you want a forward-secure ratcheting secure messenger (regardless of your message lengths or the duration of conversations).

* If it's to back things up, you want a secure backup system like Tarsnap, and even if you don't, your system's sector-level symmetric encryption also does this. Asymmetric encryption is relatively high-risk! You don't want it unless you absolutely need it!

* If it's to send files to people, you want a secure file transfer system; you're not looking to transform the file itself, but rather to establish an end-to-end secure transport for the file.

* If it's to do secure package distribution, you want a simple file signing system, and OpenBSD already nailed this: it's called signify, and the portable compatible variant of it is minisign.

* If it's a component of an application you're designing, what you want is a library that encrypts blobs, not a program that encrypts files. Use libsodium.

I'm not denying that there are cases that don't fit any of these buckets, but I'd be interested in hearing what they specifically are.

I'm a lot less interested in hearing things like "sure I want a ratcheting secure messenger but I also want to run my own server" because that's not my point. I want a use case that fundamentally demands a standalone file encryption program, not a argumentum-ad-Rube-Goldberg for why you're duct taping something together with a file encryption program to accomplish backup or package distribution or whatever.

The opposite of what you're saying is true. File transfer is especially straightforward. Group chat on secure messengers works far better than it ever did with PGP. And, incidentally, there is no 10-year rule on cryptography.

Good! So what are the solutions? What file transfer approach

(1) Doesn't require an active connection between sender and receiver over the internet for the duration of the transfer (2) Doesn't require a shared secret

What group chat secure messenger

(1) Doesn't rely on a central server operated by someone else (2) Doesn't use PII as the basis of a user's identity

These are what I regard as the most basic of requirements for each need. PGP provides them (in broken, hard to use ways); others have struggled. If you actually do have solutions here, rather than just complaints about PGP, I do want to hear them. But you've taken this thread down a rabbit hole rather than respond to my original point, which was about the limitations of the suggested alternatives.

I'm sorry for being snippy this morning. Read the /r/linux response to the PGP post to get an idea of what my baseline assumptions are about technologist disengaged with cryptography who have strong opinions about which cryptosystems people should use. But I shouldn't be projecting that on random people on HN, and I apologize for doing that to you.

My take is this (unless otherwise stated, "you" is the rhetorical "you", not you specifically):

1. PGP is bad and should be disfavored. Moreover, for some of its use cases, most especially "secure email", PGP flat-out doesn't work, and people need to be warned away from it. Most users will never see this HN thread and are getting their advice third- or fourth-hand. It's important that the "source" node for game-of-telephone graph have clear, sound advice. "Stop using PGP ASAP" is the most responsible advice I can offer.

2. The mainstream modern secure messengers are better than anything else technologists have provided to end users. If you're protecting serious things --- and the PGP team certainly claims to be doing that, so when you dip into conversations about PGP and its alternatives, you need to keep in mind that you're dipping into a game of telephone that ends with dissidents in countries like Venezuela where there are death squads --- Signal or something like it is the best you're going to do. You can be annoyed by this, and you're entitled to your opinion, but not to your own facts.

3. Nerds (I am one of those, btw) generally want something that (1) doesn't bootstrap off phone numbers and (2) lets people run their own servers. My interest in strong privacy engineering means, frankly, I don't give a shit about federation. I'm convinced that Moxie is right: federation means lowest-common-denominator protections; see Matrix, which has for years now been operating a network of off-by-default opt-in-only poorly-supported end-to-end encryption while at the same time being a darling of message board nerds. You don't have to disavow Matrix to be serious about security and privacy; I wish the project the best, too. But you can't be recommending it to immigration lawyers and foreign activists and demand to be taken seriously about security/privacy engineering (you didn't do that, but the modal "lol signal" nerd does), and I will strike down with great vengeance and furious anger anyone who tries to interpose themselves as an authoritative "source" of cryptographic advice and broadcasts to the world that Matrix is a reasonable option for those people.

4. I'm not a cryptographer, but one of my partners is, and I am myself a cryptographic vulnerability researcher (I'm comfortable assessing and breaking systems but wouldn't ask anyone to sign off on a system I designed). I feel pretty reasonably engaged with the cryptographic engineering community, which is extremely distinct from "people with strong opinions and affiliations with one or more well-known open source crypto-adjacent projects". It is "challenging" for me to hear things like (paraphrasing) "the experts I pay attention to say that you should wait a decade before using new cryptography". There is no such rule and, really, no way to escape the fact that if you're going to evaluate cryptosystems, you either need to develop the domain knowledge to do so based on intrinsic arguments, or enough domain knowledge to know whose recommendations are credible.

So my take is: I think you would have trouble coming up with a cryptography domain expert who will tell you our recommendations are "bad" (and, in fairness, one of the reasons that's the case is that our recommendations are vetted). Wormhole is fine --- pretty great, in fact. Be happy there's a system you can realistically use; it's good news. Ordinary people, like immigration lawyers, can't yet realistically use it, because it's a command line tool. I think that's going to change this year, but in the meantime, Signal does file transfers more safely than PGP does, so they should use that. Meanwhile, nerds like us can send files to people without keyservers and without giving up phone numbers. Or, if you don't have, like, access to the Internet, you can do something else.