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

31–40 of 100 posts

Re: Opmsg – A GPG Alternative

#31

Post by tatersolid »

cpach wrote: post #24
Avamander wrote: post #17

Earlier quoted context omitted.

To be fair e-mail is garbage trough-and-trough. You can't even use SNI, nothing cares about certificate validity, even less about Staple and CT.

How about MTA-STS? I guess that improves the situation a bit, no?

Not really. Until MTA-STS is deployed in “hard fail” mode by almost everybody it doesn’t matter.

Similarly, SPF/DKIM did not solve spam because nobody was willing to really drop incoming mail with bad or missing signatures.

Email is an “ossified” protocol. It should fade away, and be replaced with something else modern and secure like a “federated Signal”.

If that something else allows anyone to send to anyone without permission, it too will be killed by spam.

Re: Opmsg – A GPG Alternative

#32

Post by burgerdev »

phicoh wrote: post #28
zaarn wrote: post #18

Earlier quoted context omitted.

RSA is hard to implement and requires a lot of key material to change hand. On the flipside, a Ed25519 or Ed448 key can be reasonably dictated over phone (though you might need three minutes) and put into small low-res QR codes. Additionally, Ed25519/448 are dead simple to implement; following the reference from the RFC documentation, you can implement a safe cryptographic method (encrypt/decrypt/sign/verify). You ac…

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…

Which aspect of elliptic curves would you like to understand better? The original paper for Curve25519 contains a dedicated subsection for attack models, for example, and leaves only marginal room for hidden backdoors with its detailed reasoning about curve parameter choice. The implementation of EdDH or EdDSA is specified in RFCs that are explicitly written to be "fool-proof", as others already commented.

Re: Opmsg – A GPG Alternative

#33

Post by zaarn »

phicoh wrote: post #28
zaarn wrote: post #18

Earlier quoted context omitted.

RSA is hard to implement and requires a lot of key material to change hand. On the flipside, a Ed25519 or Ed448 key can be reasonably dictated over phone (though you might need three minutes) and put into small low-res QR codes. Additionally, Ed25519/448 are dead simple to implement; following the reference from the RFC documentation, you can implement a safe cryptographic method (encrypt/decrypt/sign/verify). You ac…

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 in 2D space and RSA in Modulo space. I have implemented EC myself, the underlying math isn't that much more complicated, really, than RSA.

>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.

Not only dictating over phone but for example typing a SSH key over a serial line while not being able to copy-paste directly. I've had to suffer than with my RSA4096 key once and it's NOT pleasant at all.

it also means you have much less overhead for the protocol (DH and KEX with Ed25519 only need 32 bytes of space per step instead of kilobytes)

Re: Opmsg – A GPG Alternative

#34

Post by ForHackernews »

maxnoe wrote: post #30
cpach wrote: post #23

Earlier quoted context omitted.

I would love to see a sound implementation of secure e-mail, but I also believe that such a system should not be built on top of SMTP. Signal’s cryptography seems stellar, but to me it feels a bit weird to use instant messaging as a full replacement for electronic letters . I’m guessing here, but it would probably not be impossible to build a more traditional e-mail client on top of the Signal Protocol.

I don't see why this should not be possible. Isn't this mainly about adding a a subject metadata field an a client that just displays messages differently, enables sorting into directories and so on? Is there a real technical difference between messaging and long form emails that I don't see?

Email is based on open, federated protocols. Every successful instant messaging service (sorry XMPP) as been a single closed provider.

Re: Opmsg – A GPG Alternative

#35

Post by phicoh »

burgerdev wrote: post #32
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…

Which aspect of elliptic curves would you like to understand better? The original paper for Curve25519 contains a dedicated subsection for attack models, for example, and leaves only marginal room for hidden backdoors with its detailed reasoning about curve parameter choice. The implementation of EdDH or EdDSA is specified in RFCs that are explicitly written to be "fool-proof", as others already commented.

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 backdoors, though at some CCC congress DJB described how you could use a similar process to add backdoors.

So basically, EC is based on magic. We cannot prove it is bad, we just have to hope there is no hidden magic.

Note you say 'only marginal room'. Soon the whole world will use exactly one curve. With 'only marginal room for hidden backdoors'.

I feel way more comfortable to know that with RSA what you see is what you get.

Re: Opmsg – A GPG Alternative

#36

Post by bscphil »

masklinn wrote: post #8
mikorym wrote: post #6

I think a perhaps unclear part of the recent post "The PGP Problem" is that PGP is bad for email . If you don't use it for email, I don't see it as really a problem. Unless, maybe, you are a reporter or otherwise not clear on the principles behind using something like GPG. I think personally that the point about all the discussion is that for laypeople PGP and email is just too complicated (even for myself as a progr…

> I think a perhaps unclear part of the recent post "The PGP Problem" is that PGP is bad for email. If you don't use it for email, I don't see it as really a problem. You're apparently asserting that Latacora's "The PGP Problem" states PGP is only bad for email. I can only assume you didn't even bother the article? Because it states that PGP is bad: * period and in its entirety, in fact most of the article (section 1…

So what's the alternative, for asymmetrically encrypting arbitrary binary data?

For sending such data to others, the Latacora article suggest a tool that I've never heard of or heard recommended by other experts called "Magic Wormhole". It's a new tool that (from what I call tell) has a whole crapload of limitations and assumptions that PGP does not have: https://magic-wormhole.readthedocs.io/en/latest/welcome.html...

One of the most severe is that it apparently requires both ends to have active internet connections to transfer the data over the wire between them. As I type this, I'm visiting my parents who have 5 Mbps internet. Let's hope that file isn't big or my contact has the time and patience to wait if it is! The other is that it apparently relies on a shared password, which just takes us back to encryption before the very problem PGP was designed to solve...

For simply "encrypting files", even Latacora gives up and says "use PGP"!!

As a side note, though I agree with them that PGP is not good for secure messaging, I don't find their alternatives convincing there either. Signal and Wire don't have solid group chat capabilities that don't rely on a single central server run by a third party and don't require private information like a phone number to use. I consider that absolutely basic for a good messenger. At least PGP, though very faulty in this area, is designed to be used over existing protocols like email to make them secure, so it doesn't have the last two limitations.

Re: Opmsg – A GPG Alternative

#37

Post by blattimwind »

lifeisstillgood wrote: post #20
blattimwind wrote: post #14

Earlier quoted context omitted.

A random key is used to encrypt the email, then that random key is asymmetrically encrypted using the recipient's public RSA key. You do not use your own key to encrypt mails to someone else. Indeed, you can send encrypted emails without even having a key of your own.

So I actually re-read and followed links (I mean whats wrong with lazy assumptions anymore) tptacek's "why email is insecure" post is here: https://news.ycombinator.com/item?id=16088386 And yes thats what he says in the original latacora post. I read the article '''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)''' So I made the…

> So I made the (incorrect) leap to pgp using the long term key to encrypt files. My bad.

It does. Which is why PGP has no forward secrecy and if I steal your key I can decrypt all your past and future mails.

Re: Opmsg – A GPG Alternative

#38

Post by upofadown »

The perfect forward secrecy here seems to involve deleting a "persona". I an not sure how that is any different from doing PFS by deleting a PGP subkey. Like with PGP if you do this you lose email archived under that persona. There is no automation to re-encrypt the archive with a different key.

So I am not really sure if this has a killer feature that would make anyone want to go to the bother of abandoning PGP...

Re: Opmsg – A GPG Alternative

#39

Post by ClumsyPilot »

phicoh wrote: post #35
burgerdev wrote: post #32

Earlier quoted context omitted.

Which aspect of elliptic curves would you like to understand better? The original paper for Curve25519 contains a dedicated subsection for attack models, for example, and leaves only marginal room for hidden backdoors with its detailed reasoning about curve parameter choice. The implementation of EdDH or EdDSA is specified in RFCs that are explicitly written to be "fool-proof", as others already commented.

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…

99.999% vulnerabilities come from bad implementation, not "magic"!

Re: Opmsg – A GPG Alternative

#40

Post by SimplyUnknown »

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.

Post reply on HN