Live data from Hacker News

21 years after the request OpenPGP support gets added to Thunderbird

bugzilla.mozilla.org

271–280 of 281 posts

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#271

Earlier quoted context omitted.

> and it's ok to leak metadata? How could Signal (or other client-server protocol) not leak metadata? It is true that OpenPGP leaks more metadata than necessary (e.g. Subject), but seems to me that any efficient message protocol needs to leak at least three most important metadata - source, destination, time. One could avoid leaking destination by broadcasting encrypted to many receivers (when only the true one can d…

Signal has been working on features like "sealed sender", which encrypts the source metadata: https://signal.org/blog/sealed-sender/ I don't know if they can do anything about destination or time, but even hiding the source seems like a significant advancement.

How does that even work? The only way to encrypt the sender is to send every (encrypted) message to everyone and let the clients drop the ones they can't encrypt. On a Phone. I hope they give out free batteries.

The post mentions some kind of "short-lived" pseudo-sender, which is vulnerable to the same metadata analysis.

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#272
post #266

Earlier quoted context omitted.

No. We've got a threadful of arguments here in which you simply refuse to engage. You don't get to superciliously demand Socratic satisfaction, wave around your list of logical fallacies and mumble oracularly about koans and enlightenment. You have to make an argument otherwise what you're doing is simply rude preening. It's fine if you have nothing to say. You don't get to (at least, publicly) pretend you've actuall…

This all started when you said something to the effect that "packet oriented formats" were bad. When asked to clarify you switched the topic to how flexibility in cryptography was bad because it could lead to downgrade attacks. I pointed out that downgrade attacks were not really possible in a data at rest application and that the article you linked to was about data in flight applications. That's it. That's the actu…

you switched the topic to how flexibility in cryptography

I never said that. You're replying to someone else.

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#273

Earlier quoted context omitted.

> By the way, the archaic meaning of "regulated" means "properly disciplined and drilled". It did not refer to control or supervision by a state. That still leaves open the question of what levels of discipline and drilling the (federal or state) government could demand of someone for them to be included in the Militia. It is already accepted that felons and the mentally ill may be prevented from exercising 2nd Amend…

The government cannot demand anything. The well-regulated part is a justification clause. Imagine if the 2A said this: > "A well tailored suit, being necessary to a sharply dressed citizenry, the right of the people to keep and wear clothing, shall not be infringed." Does this mean that the government now has a right to force dress codes on people so that their suits are well tailored? Also justification clauses have…

Great points, thank you, but I think I still disagree.

In the absence of the 2A, the government would have the power to ban any weapon (using the same authority they have to ban weapons that are not covered by the 2A today). By contrast, under your proposed fictional constitution, there would be no underlying basis for the government to control clothing generally, so your 2A wouldn't expand or limit the sorts of clothing allowable.

As for your second point, I interpret the "justification clause" as saying that all retrospective laws are ...unjust, and that "No such laws" means "No retrospective laws". The hypothetical of a ...just ex-post facto law is ruled out by definition.

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#274
post #248

Earlier quoted context omitted.

Would you know if it failed?

If it would "fail" and there would be no consequences so I could't tell if it failed or not - would it make a difference?

If the failure were discovered by you a year later, realizing that all you thought was protected was in an adversary's hands.

I'm suggesting that "seems fine so far" is not effective at evaluating solidity of cryptographical usage.

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#275

Earlier quoted context omitted.

Signal has been working on features like "sealed sender", which encrypts the source metadata: https://signal.org/blog/sealed-sender/ I don't know if they can do anything about destination or time, but even hiding the source seems like a significant advancement.

How does that even work? The only way to encrypt the sender is to send every (encrypted) message to everyone and let the clients drop the ones they can't encrypt. On a Phone. I hope they give out free batteries. The post mentions some kind of "short-lived" pseudo-sender, which is vulnerable to the same metadata analysis.

Encrypting the sender is pretty easy. Deliver the encrypted message+sender at the destination. Only the receiver will be able to decrypt it and see who the sender was.

Encrypting the receiver is a lot harder though. It will probably involve dropping off the message at some central location and some very fancy cryptography. Secure multi-party computation [0] will probably be involved. I don't know if it can be made scalable though.

[0] https://en.wikipedia.org/wiki/Secure_multi-party_computation

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#276
post #253

Earlier quoted context omitted.

> software update cryptography is both a solved problem (just use signify) Well, just use TUF [1] and in-toto [2] ;) [1] https://theupdateframework.io/ [2] https://in-toto.io/

Note that TUF is great for things with multiple contributiors (think npm or pypa). For the simple case of "a single publisher publishes update for a single product", TUF is an overkill. Something like signify or seccure will be way easier to set up and use.

signify is nice when key distribution, revocation, and rotation is handled for you... but how do you do that securely for many different publishers on a single repo?

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#277
post #275

Earlier quoted context omitted.

How does that even work? The only way to encrypt the sender is to send every (encrypted) message to everyone and let the clients drop the ones they can't encrypt. On a Phone. I hope they give out free batteries. The post mentions some kind of "short-lived" pseudo-sender, which is vulnerable to the same metadata analysis.

Encrypting the sender is pretty easy. Deliver the encrypted message+sender at the destination. Only the receiver will be able to decrypt it and see who the sender was. Encrypting the receiver is a lot harder though. It will probably involve dropping off the message at some central location and some very fancy cryptography. Secure multi-party computation [0] will probably be involved. I don't know if it can be made sc…

> Encrypting the sender is pretty easy. Deliver the encrypted message+sender at the destination.

That's the point. If the sender is encrypted, what's "the destination"? The IPv4 space? A random ID that represents the sender? How does that change the metadata angle?

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#278
post #275

Earlier quoted context omitted.

Encrypting the sender is pretty easy. Deliver the encrypted message+sender at the destination. Only the receiver will be able to decrypt it and see who the sender was. Encrypting the receiver is a lot harder though. It will probably involve dropping off the message at some central location and some very fancy cryptography. Secure multi-party computation [0] will probably be involved. I don't know if it can be made sc…

> Encrypting the sender is pretty easy. Deliver the encrypted message+sender at the destination. That's the point. If the sender is encrypted, what's "the destination"? The IPv4 space? A random ID that represents the sender? How does that change the metadata angle?

If I deliver a bunch of bytes at jet@spiegel.com then that's the destination. Now you can decrypt it with your public key and get

`Have a nice day. Regards, sobani`

and see that I'm the sender.

If I'm worried about leaking my IP address, I can use something like Tor.

I'm confused why you think the sender needs to be known in any way to allow bytes to be delivered to your mail server.

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#279
post #8

I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me. The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.

S/MIME is the closest to dead simple solution, but it requires trusting certificate authorities. It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.

S/MIME does not protect from phishing.

Re: 21 years after the request OpenPGP support gets added to Thunderbird

#280

Earlier quoted context omitted.

There are many things wrong with both the UX and internal cryptographic design of PGP. Here are a few articles that go over those issues in more depth: https://blog.filippo.io/giving-up-on-long-term-pgp/ https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://blog.cryptographyengineering.com/2014/08/13/whats-ma... https://secushare.org/PGP https://www.techrepublic.com/article/why-pgp-is-fundamentall...

Yet it's the best we got right now.

Well there's http://age-encryption.org/ and raw ed25519.
Post reply on HN