Live data from Hacker News

Ask HN: What is your favorite method of sending large files?

news.ycombinator.com

21–30 of 363 posts

Re: Ask HN: What is your favorite method of sending large files?

#21
post #19

Earlier quoted context omitted.

IMO, GPG is simply not a good tool and it should be replaced. Others have said it better than I can. See e.g. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

That's said often about any tool which has been around long enough. People without experience come around and think they can replace an old tool with a better one, but it's usually only ignorance of either the complexity of the task, knowledge of using the tool properly, or both.

GPG is just not a very good tool. I think 'tptacek explained it quite well in the article I linked.

With that said, Magic Wormhole is also a very good tool for transferring files. It will encrypt in transit. So for many files, using a separate encryption tool is not necessary. (So far I haven’t tried it for large files.)

Re: Ask HN: What is your favorite method of sending large files?

#24
post #19

Earlier quoted context omitted.

Why a new tool? How is this better than gpg symmetric encryption, considering gpg is installed/available effectively everywhere? Encrypt: gpg --symmetric file.dat (enter a password) Decrypt: gpg --decrypt file.dat.gpg > file.dat (enter the password)

IMO, GPG is simply not a good tool and it should be replaced. Others have said it better than I can. See e.g. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

I don't see how any of the points in the article are relevant to the symmetric encryption method I posted. Yes, GPG can do a lot, and yes, some parts of it are kinda ridiculous. But symmetric pre-shared-key encryption/decryption is a solved problem, and I'd much rather trust GPG than some random's git repo.

Re: Ask HN: What is your favorite method of sending large files?

#26
post #19

Earlier quoted context omitted.

IMO, GPG is simply not a good tool and it should be replaced. Others have said it better than I can. See e.g. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

I don't see how any of the points in the article are relevant to the symmetric encryption method I posted. Yes, GPG can do a lot, and yes, some parts of it are kinda ridiculous. But symmetric pre-shared-key encryption/decryption is a solved problem, and I'd much rather trust GPG than some random's git repo.

The author of Age is definitely not some rando.

But if you like GPG then feel free to continue using it.

Re: Ask HN: What is your favorite method of sending large files?

#27
post #21

Earlier quoted context omitted.

That's said often about any tool which has been around long enough. People without experience come around and think they can replace an old tool with a better one, but it's usually only ignorance of either the complexity of the task, knowledge of using the tool properly, or both.

GPG is just not a very good tool. I think 'tptacek explained it quite well in the article I linked. With that said, Magic Wormhole is also a very good tool for transferring files. It will encrypt in transit. So for many files, using a separate encryption tool is not necessary. (So far I haven’t tried it for large files.)

I want to comment on that article you keep referring to, but I don't want to clutter up the top of the thread so I'll do it here.

The author really wants to dislike PGP, but the reason everyone trusts PGP is because it's been around forever. Yeah there've been deficiencies, just like there've been deficiencies in OpenSSL, but that doesn't make it a bad tool. I could go on but this xkcd sums it up: https://xkcd.com/2347/

>Absurd Complexity / Swiss Army Knife Design

Git is complex, yet effectively every project ever uses it. The reason is you're fine to avoid the edge-cases and just focus on the main functionality, but that one time you need to do something ridiculously hacky, there's a tool to do it, instead of having to roll your own solution.

>Backwards Compatibility

Would you rather your software not have backwards compat? GPG has sane defaults, and everyone you talk to using modern versions will be secure by default. Not sure what the author is going on about with weak default password encryption:

    $ gpg -vv --symmetric test.txt 
    ...
    gpg: using cipher AES256
    gpg: writing to 'test.txt.gpg'
>Obnoxious UX

I don't really find GPG any harder to use than Git. http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/

>Long-Term Secrets

By default, GPG keys expire in a year.

>Broken Authentication

I've never heard of any of this. Sign and encrypt, by default you get AES256 encryption and a SHA512 digest:

    $ gpg --sign --encrypt test.txt
    ...
    $ gpg -vv -o /dev/null --decrypt test.txt.gpg
    ...
    gpg: encrypted with 3072-bit RSA key, ID 74588E74DDD483BC, created 2020-09-02
      "test"
    gpg: AES256 encrypted data
    gpg: binary signature, digest algorithm SHA512, key algorithm rsa3072
>Incoherent Identity

Have an identity. Have other people verify it. Trust based on that. It's the same way the PKI works, you know, that thing that runs the entire internet. Except you don't need to trust CAs anymore.

>Leaks Metadata

He's not wrong about this one, normally you can see who's ID a message is encrypted for. If you're trying to be sneaky just use symmetric encryption I guess, it feels like a different use case.

>No Forward Secrecy

Definitely a different use case. There's no case where I want to decrypt a packet from the middle of a TLS conversation a few years later. But an encrypted attachment in an old email?

>Clumsy Keys

How are GPG keys harder to handle than SSH keys? Both are just blocks of base64 (gpg --export-secret-keys -a)... one is 80 lines while the other is 50, but does it really matter?

>Negotiation

Same argument as Backwards Compatibility, I think.

>Janky Code

The page he linked has 27 CVEs. Over the last 15 years. For comparison, OpenSSL has over 200.

Re: Ask HN: What is your favorite method of sending large files?

#28
Personally I would use my own Nextcloud instance for up to 20-30GBs. Not sure about TBs.

What about using "Firefox Send"? (I never used it so far)

https://support.mozilla.org/en-US/kb/send-files-anyone-secur...

I read that the limit is 1-2.5GBs => maybe you could break down the file and upload it in multiple pieces... .

EDIT: oopps, Firefox Send doesn seem to be available anymore - https://support.mozilla.org/en-US/kb/what-happened-firefox-s...

Post reply on HN