Live data from Hacker News

Modern Alternatives to PGP

blog.gtank.cc

231–240 of 261 posts

Re: Modern Alternatives to PGP

#231
post #229

Earlier quoted context omitted.

Interesting that the comment above is off-and-on turning grey. It's pragmatic, informative, and highlights that bashing gpg for this specific use case, without naming something better...is arguably worse than saying nothing. Why downvote it instead of just naming a better choice? What's the big secret?

I downvoted it for making the unhinged argument that a poor KDF is a feature because it encourages users to select better passwords. I downvote lots of things. On Hacker News, we're explicitly encouraged to downvote disagreement, especially when verbalizing that disagreement will just clutter up the thread. Everyone gets downvoted. I've been downvoted all over this thread. You were just downvoted a minute ago. The on…

"making the unhinged argument that a poor KDF is a feature because it encourages users to select better passwords."

Where does it say that? It says a better kdf would improve the security of shorter passwords. I don't see anything that suggests a poor kdf is a feature.

The kdf used for "gpg -c" also seems better than "openssh enc". And we've still not heard what the reasonable alternative is for symmetric/password file encryption is. So, I'm sticking with gpg for that use case.

Re: Modern Alternatives to PGP

#232
post #231

Earlier quoted context omitted.

I downvoted it for making the unhinged argument that a poor KDF is a feature because it encourages users to select better passwords. I downvote lots of things. On Hacker News, we're explicitly encouraged to downvote disagreement, especially when verbalizing that disagreement will just clutter up the thread. Everyone gets downvoted. I've been downvoted all over this thread. You were just downvoted a minute ago. The on…

"making the unhinged argument that a poor KDF is a feature because it encourages users to select better passwords." Where does it say that? It says a better kdf would improve the security of shorter passwords. I don't see anything that suggests a poor kdf is a feature. The kdf used for "gpg -c" also seems better than "openssh enc". And we've still not heard what the reasonable alternative is for symmetric/password fi…

I think you're right, and that I misread the comment. I fixed my vote. Thanks! See! The system works!

Re: Modern Alternatives to PGP

#233
post #223
post #220

Earlier quoted context omitted.

Also, if you're sending an encryption key you have to make sure it's a good key, ie generate it from a reliable source of random and with a sufficient length, whereas magic wormhole's password is automatically generated for you.

PAKE takes care of that. Watch the parents nice talk: https://youtu.be/oFrTqQw0_3c

Yes, that's what I'm saying: GP's point is that if you have a secure channel you might as well send the encryption key, but in order to do that you have to be careful about generating it correctly, whereas PAKE give you the possibility to exchange something far simpler.

Re: Modern Alternatives to PGP

#234
post #222

Earlier quoted context omitted.

Well, it's nice when phone is considered secure channel. It's not so for many serious applications, however. PGP invented to deal with situations when you communication channels are untrusted. See, no one says your software is bad, but when it is marketed as a better alternative to PGP it's not true, and worse, it's absolutely irresponsible thing to do.

According to parents nice talk[1] you can add a verify switch that lets you compare the signature of the actual key. So a public authenticated channel is enough. [1] https://youtu.be/oFrTqQw0_3c

I'm not sure we are on the same page here. Having control over a channel you use to pass your code, I can receive your secret file, I just need to be quicker than a legitimate recipient. How this '--verify' flag will help you then?

Re: Modern Alternatives to PGP

#236

Earlier quoted context omitted.

Flag won't make it better. If user needs to run own server, it kills the only advantage in comparison with PGP - relative simplicity.

No, angry commenter, that is not the only advantage Magic Wormhole has over PGP.

Please, don't try to interpret my mood, it can quickly make it childish.

Feel free to argue over other advantages you believe it has.

Re: Modern Alternatives to PGP

#237

Earlier quoted context omitted.

still, from a dev perspective it's not always clear what tool to use for the task. That's a lot of bike shedding for something that shouldn't be a problem in the first place: email or whatever communication system we will use in 20 years needs to have encryption baked in by default. Storing and sharing data safely need to be a first class feature of all OS and browsers.

What's the term of art for bikeshedding something so long that you give up and opt for a solution that is materially worse than all the bikeshedded options? Because that's what you're doing when you debate cryptography and give up and use OpenPGP.

Where did I say that we need to give up and use PGP?

Re: Modern Alternatives to PGP

#238

Earlier quoted context omitted.

Its a pain in the ass because nobody has created a user friendly UI for that, but in itself it is a powerful technique to establish trust.

PGP’s UI isn’t user friendly to begin with, in fact, it’s notoriously bad. But that’s not the point. You try to get PGP to verify a signature without importing the key into a keychain fist. The purported benefits of web of trust are completely irrelevant, the problem is that PGP handcuffs you to the web of trust and web of trust is often unwanted. You have to reduce and simplify your trust to something that PGP under…

Pgp does not handcuff you to the web of trust. Actually most people who use pgp do not use the web of trust but instead compare fingerprints or do trust on first use.

If you do not understand this your argument is moot.

It is not because you learned in class that pgp works with the web of trust that this is what actually happens in practice

Re: Modern Alternatives to PGP

#239
post #224
post #218

Earlier quoted context omitted.

if you encrypted it with a public key then you also need a signature, I am not sure what the parent meant though.

I'm not sure I follow. If you are decrypting with a key, either you trust it or you don't. It works or doesn't. That is, why use a public key scheme, for private encryption? It is literally made to establish identity with someone else. Not yourself. Even if you sign things for personal use, that is just to confirm nothing was tampered with. Which, if it was encrypted with a key, is already guaranteed. Otherwise it wo…

The point is anyone can encrypt to your public key, thus, anyone could create a "backup". They won't be able to decrypt it, only you, but still having a backup that you think was created by you but wasn't can be problematic.

Re: Modern Alternatives to PGP

#240
Maybe I'm missing something here but I'm not sure how nacl/box and nacl/secretbox can replace openpgp in the pass use case.

Yes nacl/box and nacl/secretbox can handle the encryption and decryption part of pass, but how do they handle the key management part? With pass+openpgp, I have my key-pair, while the private key was protected by a strong passphrase, everytime I use pass it asks me for the passphrase to unlock my private key, then it's done.

With nacl/box, I need to generate a random key-pair, and then how do I securely store the private key? Maybe I use the nacl/secretbox to encrypt it and store as a file in my computer? But the key part of nacl/secretbox is a fixed-size [32]byte, so that limits how long my passphrase can be? There's also a fixed-size [24]byte nonce, how do I store that in my computer? Maybe I should just combine them to get a [56]byte as the passphrase? That may or may not be long enough as I would like it to be.

Post reply on HN