I've been using croc for a few months and it works perfectly: https://github.com/schollz/croc . End to end encryption, command line only, and claims to be "faster than wormhole, rsync, scp through compression and multiplexing (speedups 1.5x to 4x)".

I've been using croc (as alternative for for a while, it's fast and reliable. Personally I think it's better than magic-wormhole in the way that it can be statically linked as a standalone Go binary which is easier to distribute in an environment that one does not have root / administrator priviledge, especially when one has to use a Windows machine with domain/AD login but not a member of local Administrators...

Just FYI, there's a go implementation of magic-wormhole that satisfies the requirements you've listed: https://github.com/psanford/wormhole-william

cryo a new file manager also supports end-to-end encrypted file transfers.

https://cryonet.io

For confidential content OnionShare is another good option.

https://onionshare.org/

If I might ask a lazy question - do any of these work with basic (e.g easily available on a lightweight container) command line tools on the terminal? I assume not since they must all be Javascript-based.

Found this: https://github.com/timvisee/ffsend

Thanks for linking, dev here. Yes, perfectly usable for automation!

ffsend excellent tool. Ffsend is inspiration for me to make 'ele'

https://github.com/prakis/helloele

Ele is a command line tool works with your own cloud. Main difference from ffsend and other cmd tools is no need to share links, files are referred by file-indexes.

Sounds cool! Will check it out later today.

magic wormhole is a command line tool.

Neat tool. Just read the documentation, for others interested, it is a command line tool where you enter a send command on one machine, it generates a 16-bit one time code, then you type a receive command on another machine (which includes the one-time code) which is used to negotiate a strong shared key that is then used to transfer the file.

The initial handshake uses the 16-bit code with an interactive PAKE algorithm to generate a shared key. An attacker would need to MITM the initial connection and guess the one time code on their first guess. So this gives a network privileged attacker a 1-in-65k chance of breaking into the connection, or if they fail you would see an error message on the sender side. Offline attacks on the one-time code are not possible.

The pre-built program uses a hard-coded server for assisting in making the network connection in order to setup the initial connection (discovery, key negotiation) as well as a TURN server to assist in the file transfer. You can setup and use your own servers for discovery and transit with command line arguments.

Looks like this;

  % wormhole send README.md
  Sending 7924 byte file named 'README.md'
  On the other computer, please run: wormhole receive
  Wormhole code is: 7-crossover-clockwork
 
  Sending (<-10.0.1.43:58988)..
  100%|=========================| 7.92K/7.92K [00:00<00:00, 6.02MB/s]
  File sent.. waiting for confirmation
  Confirmation received. Transfer complete.

And on the receiver side;

  % wormhole receive
  Enter receive wormhole code: 7-crossover-clockwork
  Receiving file (7924 bytes) into: README.md
  ok? (y/n): y
  Receiving (->tcp:10.0.1.43:58986)..
  100%|===========================| 7.92K/7.92K [00:00<00:00, 120KB/s]
  Received file written to README.md

I believe the "7" in the wormhole code is what's used so that the two peers can find each other when connecting to the "Rendezvous Server" which forwards messages between the two machines to facilitate the key generation.

Very nice summary!

Dropbox Transfer follows the same encryption protocols as the rest of Dropbox. While at rest, all Dropbox files are encrypted, but end to end encryption would severely limit the functionality of heavily used features like previews and search.

We're always looking to improve and certainly open to suggestions (we have a feedback form on the Transfer page just for these kind of suggestions that the Transfer team actively monitors!).

Not using end to end encryption for personal files in 2020 is fail by design. It's not only a problem that people at Dropbox can read the content, numerous data breaches have shown that this is not a good choice and never will be.

The sad truth is that users usually don't understand the implications until it's too late.

Features like search and preview can be implemented at the client side as well and synchronized between trusted peers. This might be harder to do but it's possible.

Please don't get me wrong, I admire the technological achievements done at Dropbox and their excellent engineers. But sooner or later they need to switch to a secure model as more and more people gain awareness of the security and privacy implications.

Tresorit Send is another good end-to-end encrypted option (free, files up to 5GB):

https://send.tresorit.com/