[hiq]

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/).

[bscphil]

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.

[tptacek]

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.

[bscphil]

Thank you for taking the time to give a thoughtful response, in this and your other comment. Here is what I take to be the use case - it concerns whistleblowers, who have among the most serious real world security needs.

I'm thinking of sending files to people. Large dumps of documents and other data from several GB to several TB. Imagine that any of the following apply:

* The data is in a secure location and can only be exfiltrated by the internet, not via a thumb drive. (And so my connection will be closely monitored.)

* The data needs to be sent to someone with whom I don't have another means of secure communication. In other words, I can't use symmetric encryption with a pre-shared key.

* I or my correspondent have slow or unreliable internet connections and maintaining a direct connection between each other would be difficult or impossible for the length of time needed to transfer the data.

* I or my correspondent are being closely monitored by the authorities, such that connecting directly to each other or using intermediaries that would allow us to do so is an unacceptable risk.

If any of these situations apply, I can't use Wormhole or similar approaches. I need something that will allow me to encrypt files for my correspondent without a shared secret, where I can upload those encrypted files to a service like Google Drive for them to download on their own time. This is precisely what PGP does.

I don't think it's unrealistic to imagine situations in which a source or journalist has one or more of these issues. I would very much like to see an alternative for use cases like this one. I'm in agreement with you that PGP is bad in many ways, from usability to the cryptographic implementation. But it's hard to deny that it's a remarkably robust solution to problems like this one.

[tptacek]

I guess what I don't see here is the case where (1) you can safely upload a .PGP file to Google Drive (or anywhere across the organization's network perimeter) without immediately triggering an investigation (PGP files being particularly easy to spot) and (2) you can't use Signal and Signal's built-in file transfer.