Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Opmsg – A GPG Alternative

github.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Opmsg – A GPG Alternative

#61

Post by bscphil »

tptacek wrote: post #59
bscphil wrote: post #58

Earlier quoted context omitted.

Maybe? It depends on your requirements. Don't most experts recommend extreme caution with cryptography approaches and software that's less than a decade old? Has that changed? Do we move fast and break things now too? Would also like to hear your thoughts on why / whether Signal and Wire are actually good recommendations.

I'll tell you what I don't understand. I don't expect random engineers on HN to be especially crypto-literate, nor should they be: it's a super-specialized field that demands a lot of spare storage capacity in your brain, and a lot of us had enough algebra after Algebra II in 10th grade. Engineers who specialize have a whole huge variety of things to pick: machine learning, distributed systems, optimization, network…

I'm not sure what this is in response to, actually. I'm not expressing any particular opinion about cryptography. I have no opinions and I defer to experts. One thing that I have heard experts say is that we should be very hesitant to use new protocols and software in areas in which a maximum of security is needed.

So I have no opinion of Wormhole, other than to say that (1) it is new, and experts I have listened to in the past say to be wary of new approaches, and (2) it (according to its own documentation) has some rather extreme limitations that make it arguably not a good fit as a general purpose solution to encrypted file transfer.

> My thoughts about Signal and Wire are that I did a good job of relating in the post you're talking about what I think about Signal and Wire.

As I don't think I have referred to any post by you, I don't know what you think about those solutions. If you are referring to the Latacora article (I think you wrote it, but I'm not sure because it doesn't specify its authors), it says (IMO) very little about the merits of Signal and Wire compared to other systems, and nothing at all about the specific criticisms I made in my comment you originally replied to.

Re: Opmsg – A GPG Alternative

#62

Post by jcranmer »

DarkWiiPlayer wrote: post #4
masklinn wrote: post #3

Earlier quoted context omitted.

Indeed, from Latacora's recent "The PGP Problem": > Encrypting Email > Don’t. > Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is f…

If you know what you're doing, PGP can improve security. The real problem is that, the moment you're sending information to someone, you're giving that information away, out of your control. If I understand it correctly, all the above points seem to address mostly the technical aspect, that someone who means well may too easily leak previously encrypted information out of ignorance. A possible counter argument could…

Email is really difficult-to-impossible to secure correctly.

Take metadata. Because of how email works, it's effectively impossible to hide the To, From, and Date (or more accurately, the Received) headers. If you're worried about three-letter agencies, that's the only metadata they need, so you're screwed before you started. Theoretically, S/MIME allows you to encrypt additional headers (including the venerable Subject header), and has done so for 15 years, but I'm unaware of any email client that actually supports this feature, and the downgrade mode is pretty UX-hostile.

Another very challenging problem is that the flow of email pretty much destroys any chance of using a good secure cryptosystem. The email sender is not necessarily able to establish a direct, synchronous contact with the email recipient, even on a server basis. That makes protocol negotiation and perfect forward secrecy difficult. Not to mention that users generally expect to be able to open up email clients on unknown machines (especially webmail clients), which means practical key distribution tends to amount to "give your provider your keys," at which point the security advantage over the current state of all-connections-are-wrapped-in-TLS is negligible.

There's also the point that email's main advantage as a messaging system is its universality. But any new protocol is going to suffer from being supported in a small section of clients at first. If you can't get major email clients on board--and that includes webmail clients--then the universality of email is no longer an advantage in your proposed protocol. And if you're going to have to use a different client already, why bother with doing all the crap you have to deal with email syntax, MIME, SMTP, and IMAP?

About the only use case I can reasonably see for encrypting emails is in workflows like Bugzilla's "secure email" feature: the system is already relying on email for communication, there is a clear way to handle the recipient's key and protocol negotiation, and the metadata is irrelevant to secure.

Re: Opmsg – A GPG Alternative

#63

Post by tptacek »

bscphil wrote: post #61
tptacek wrote: post #59

Earlier quoted context omitted.

I'll tell you what I don't understand. I don't expect random engineers on HN to be especially crypto-literate, nor should they be: it's a super-specialized field that demands a lot of spare storage capacity in your brain, and a lot of us had enough algebra after Algebra II in 10th grade. Engineers who specialize have a whole huge variety of things to pick: machine learning, distributed systems, optimization, network…

I'm not sure what this is in response to, actually. I'm not expressing any particular opinion about cryptography. I have no opinions and I defer to experts. One thing that I have heard experts say is that we should be very hesitant to use new protocols and software in areas in which a maximum of security is needed. So I have no opinion of Wormhole, other than to say that (1) it is new, and experts I have listened to…

What experts are you listening to? Are they telling you to use PGP in 2019?

Re: Opmsg – A GPG Alternative

#64

Post by SibLiant »

SimplyUnknown wrote: post #40

Forgive me if I can't read but I couldn't quickly find the following. Is it possible to use Opmsg as a library? If you want to use GPG as library in your application right now, you can't. The best thing you can do is parse GPG output which is ... less-than-ideal at best and downright wrong and dangerous at worst. If one can use this as a library rather GPG that would be a huge win.

I've been reading about crypto lately and https://download.libsodium.org/doc/ seems to be the goto library for what you're pointing out.

Re: Opmsg – A GPG Alternative

#65

Post by bscphil »

tptacek wrote: post #63
bscphil wrote: post #61

Earlier quoted context omitted.

I'm not sure what this is in response to, actually. I'm not expressing any particular opinion about cryptography. I have no opinions and I defer to experts. One thing that I have heard experts say is that we should be very hesitant to use new protocols and software in areas in which a maximum of security is needed. So I have no opinion of Wormhole, other than to say that (1) it is new, and experts I have listened to…

What experts are you listening to? Are they telling you to use PGP in 2019?

Why do you keep nitpicking tiny aspects of what I'm trying to say? GPG sucks. Everyone agrees it sucks. The consensus of experts is that you should avoid it where possible. I have not denied any of that.

The problem is that some experts love to suggest alternatives that have severe limitations that GPG (for all its very real faults) does not have.

For 1 to 1 encrypted chats, I would trust Signal provided that OWS having my phone number (and that of my conversation partner) was not a security risk, and that I'm not facing a nation state level adversary who could take over OWS servers and push a compromised version of the app to me via update mechanisms.

In my opinion those are serious limitations that GPG does not have. And this is an area in which we're talking about the most developed alternatives (other than signing). Other areas like encrypted file transfer and group chat are even worse.

Re: Opmsg – A GPG Alternative

#66

Post by tptacek »

bscphil wrote: post #65
tptacek wrote: post #63

Earlier quoted context omitted.

What experts are you listening to? Are they telling you to use PGP in 2019?

Why do you keep nitpicking tiny aspects of what I'm trying to say? GPG sucks. Everyone agrees it sucks. The consensus of experts is that you should avoid it where possible. I have not denied any of that. The problem is that some experts love to suggest alternatives that have severe limitations that GPG (for all its very real faults) does not have. For 1 to 1 encrypted chats, I would trust Signal provided that OWS hav…

The opposite of what you're saying is true. File transfer is especially straightforward. Group chat on secure messengers works far better than it ever did with PGP. And, incidentally, there is no 10-year rule on cryptography.

Re: Opmsg – A GPG Alternative

#67

Post by bscphil »

claudius wrote: post #26
cwyers wrote: post #2

I am not qualified to review how it implements forward security, for instance. But this shares a lot of the problems that GPG has. It relies on existing mail standards, so it leaks metadata all over the place, and security can easily be defeated by "accidentally replying without encrypting." It's configurable -- every choice you have to make is a chance to make the wrong one. It implements RSA, which nobody should be…

> It relies on existing mail standards This is a feature, not a bug. Nobody actually wants to rely on a single entity (for or non-profit) for their communication. Nobody wants to be stuck in crappy Electron and mobile clients. I had some hope that Matrix may be able to alleviate those concerns and provide a modern, federated chat solutions. Unfortunately their quality of implementation seems to be rather low with slo…

> This is a feature, not a bug. Nobody actually wants to rely on a single entity (for or non-profit) for their communication. Nobody wants to be stuck in crappy Electron and mobile clients.

And nobody facing a nation state adversary wants to give their chat client their phone number. I really couldn't agree with you more on the nature of the problem and the status of the available solutions. It's really unfortunate that Matrix is as unfinished as it is. At least cross signing [1] is nearly done, which should eliminate the major issue making it unusable for anyone who's not technically competent and very dedicated.

[1] https://github.com/vector-im/riot-web/issues/9631

Re: Opmsg – A GPG Alternative

#68

Post by Mediterraneo10 »

jcranmer wrote: post #62
DarkWiiPlayer wrote: post #4

Earlier quoted context omitted.

If you know what you're doing, PGP can improve security. The real problem is that, the moment you're sending information to someone, you're giving that information away, out of your control. If I understand it correctly, all the above points seem to address mostly the technical aspect, that someone who means well may too easily leak previously encrypted information out of ignorance. A possible counter argument could…

Email is really difficult-to-impossible to secure correctly. Take metadata. Because of how email works, it's effectively impossible to hide the To, From, and Date (or more accurately, the Received) headers. If you're worried about three-letter agencies, that's the only metadata they need, so you're screwed before you started. Theoretically, S/MIME allows you to encrypt additional headers (including the venerable Subj…

Doesn’t To and From metadata leak on encrypted-message apps, too? WhatsApp, Telegram and Signal use mobile phone numbers as identifiers. In many countries now, you cannot buy a SIM card unless you show the vendor proof of identity, a copy of which is then provided to the state for its records. Therefore, any state actor that can put pressure on those encrypted-messaging services can reveal which phone numbers are talking to who, and therefore who is talking to who. Sure, the message text might still be secure if the end-to-end encryption works, but the metadata is vulnerable.

Re: Opmsg – A GPG Alternative

#69

Post by throw0101a »

zaarn wrote: post #33
phicoh wrote: post #28

Earlier quoted context omitted.

I don't understand the argument of dictating a key over the phone. If you care about that use case, you can just a well dictate the hash of an RSA public key. Nobody knowns of the NIST curves have backdoors. Nobody know s if Dan Bernstein's curve has issues. The advantage of RSA, is that we actually know how it works. I continue to be amazed that so many people advocate curves that we don't undertstand. Of course, th…

>Nobody knowns of the NIST curves have backdoors. Nobody know s if Dan Bernstein's curve has issues. There are still some differences. NIST provides some curves and doesn't explain much about them. You can read up how DJB choose the curves. It's a very neat and tidy process that is easy to follow and very reasonable. ECurve isn't terribly more complicated than RSA, they both rely on multiplication, though EC does it…

> There are still some differences. NIST provides some curves and doesn't explain much about them. You can read up how DJB choose the curves. It's a very neat and tidy process that is easy to follow and very reasonable.

You're not wrong, but to paraphrase a famous quotation: No body every got fired for following Suite B.

AES, SHA-2, and the NIST curves are approved for government crypto, and are also probably in many industry regulations. If there's ever an incident and a post-mortem audit, then it's a lot easier to explain the choice of Suite B algorithms.

Re: Opmsg – A GPG Alternative

#70

Post by throw0101a »

tptacek wrote: post #52
phicoh wrote: post #35

Earlier quoted context omitted.

Compare the NIST curves to RSA. For RSA we know there cannot be any backdoors. If you generate good quality primes you are in business (assuming you don't make mistakes elsewhere). For NIST we cannot say anything about backdoors. We don't use those curves because we don't trust NIST. Not because we have any prove they are bad. So to avoid that, there is a parameter selection process that supposedly leaves no room for…

Even Bernstein doesn't really believe the NIST p-curves are backdoored, and the Koblitz/Menezes paper makes a pretty decent case that they couldn't be, but if you want to tinfoil hat it, just do what every modern system does and use Curve25519. If any of this is new to you, though, you shouldn't be designing cryptosystems. Most people shouldn't! I sure shouldn't! It's an extremely specialized skill, and the world doe…

> but if you want to tinfoil hat it, just do what every modern system does and use Curve25519.

What is your take on the NIST curves being "officially" blessed for government data via Suite B (or whatever they're calling it)?

If it's good enough for government work, would it be good enough for us in the private sector? What are the chances the the NSA know weaknesses in Curve25519 or ChaCha like they knew about differential cryptanalysis attacks DES ahead of everyone else?

Post reply on HN