6 ms·
Related: If you need to transfer sensitive data over Bittorent, Age is a good tool for encrypting it before transmission. https://github.com/FiloSottile/age ht
by cpach 6y ago
Related: If you need to transfer sensitive data over Bittorent, Age is a good tool for encrypting it before transmission.
https://github.com/FiloSottile/age https://github.com/FiloSottile/age
- parliament32 6y agoWhy 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)
- cpach 6y agoIMO, 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 https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
- forgotmypw17 6y agoThat'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.
- cpach 6y agoGPG 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.)
- parliament32 6y agoI 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/ 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/ 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.
- theamk 6y agoDisagree. There are many tools which are way older than gpg, but still in the wide use. For example, I have not heard any arguments that people should stop using things like "rsync" or "curl".
- parliament32 6y agoI 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.
- cpach 6y agoThe author of Age is definitely not some rando. But if you like GPG then feel free to continue using it.
- ta95846893 6y agogpg symmetric encryption just derives a key from the password so theres no forward secrecy. Using bittorrent in particular opens you up to the risk of third parties getting ahold of your encrypted file and without forward secrecy the can attack the password offline which is typically much smaller that 256 bits. Using Magic Wormhole would seem to be far more secure than gpg and bittorrent since it has less risk of third party interception and uses SPAKE2 which has perfect forward secrecy. If I had to use bittorrent to transfer a sensitive file I would generating a random key and encrypt, then share the key over a different channel.
- ta95846893 6y agoOne reason age is beneficial is that it will generate a sufficiently long password for you when encrypting a file, This is a good idea if you're using a transmission protocol without a handshake. I don't think gpg has this as an option?