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

21–30 of 100 posts

Re: Opmsg – A GPG Alternative

#21

Post by petre »

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 implements EC with _fallback_ to RSA if EC is not available. Blame OpenSSL, I guess, because this relies on it. Even its CLI seems to be inspired by the atrocious OpenSSL CLI.

Re: Opmsg – A GPG Alternative

#22

Post by cpach »

masklinn wrote: post #19
wongarsu wrote: post #15

Earlier quoted context omitted.

>It implements RSA, which nobody should be using anymore Can someone elaborate a bit? My impression was that RSA is fine with long keys, elliptic curves mainly provide shorter keys, and no decent quantum resistant algorithm emerged?

https://blog.trailofbits.com/2019/07/08/fuck-rsa/ covers that. The executive summary is that while it's possible to implement and use RSA properly: * it looks easy to implement so it's common for people to roll their own (and then it's insecure or broken), ECC look hard (though aren't necessarily) so devs are more likely to use properly vetted libraries * because most of the parameters must be kept secret, good advic…

That article was discussed on HN about a week ago and there are some interesting comments on that thread: https://news.ycombinator.com/item?id=20381779

Re: Opmsg – A GPG Alternative

#23

Post by cpach »

jively wrote: post #10

The reality of the situation is that you can't remove the human factor from security. So someone copying your email to someone else is a human problem that can't be fixed - someone could just as easily photograph the screen. The reality is email will continue to be used, and there is a use case for being able to send an email securely to another person. EFail was pretty bad, but only affected HTML email. Having a mod…

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.

Re: Opmsg – A GPG Alternative

#24

Post by cpach »

Avamander wrote: post #17
ape4 wrote: post #13

The "MITM on all HTTPS traffic in Kazakhstan" issue suggests that relying on STARTTLS for email encryption isn't that great.

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?

Re: Opmsg – A GPG Alternative

#25

Post by zahllos »

wongarsu wrote: post #15
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 implements RSA, which nobody should be using anymore Can someone elaborate a bit? My impression was that RSA is fine with long keys, elliptic curves mainly provide shorter keys, and no decent quantum resistant algorithm emerged?

There's nothing cryptographically broken about RSA as a cryptosystem per se, but implementing it correctly is difficult. There have been multiple revisions to the standards for RSA over the years in response to various attacks. The current standard is PKCS#1 v2.2 (https://tools.ietf.org/html/rfc8017) and we should use RSAES-OAEP / RSASSA-PSS as primitives.

However a PKCS#1 1.5 compatibility mode with fixes for Bleichenbacher's oracle is also present in this standard and also specified in TLS 1.2 for compatibility reasons. In order not to provide an oracle, padding and other properties must be verified and a random premaster secret returned on failure instead of an error message, see: https://tools.ietf.org/html/rfc5246#section-7.4.7.1 . Note that under the other techniques, there are a lot of caveats and remarks.

Keys must also be carefully generated, as demonstrated by ROCA. In this case a specific format of primes was used to make prime number generation faster, which unfortunately also happens to be vulnerable to attack by Coppersmith's method. Any such key is weak in the sense that the private key can be recovered.

This is a quick overview. There's a lot of literature on attacks on RSA, particular parameter choice etc. So one argument against its use is the many issues that exist and the fact that even for experts, implementing it correctly is not easy.

The other point is that, compared to Elliptic Curve cryptosystems, RSA is (usually) more expensive as an operation and key generation is certainly more expensive. As a result, elliptic curves work better in constrained environments like on smartcards. If you want to do forward secrecy by periodically generating and throwing away random keys, elliptic curves can do this more efficiently - RSA by contrast would be slow.

Re: Opmsg – A GPG Alternative

#26

Post by claudius »

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 slow, laggy and resource-hungry clients and ridiculously resource-hungry servers and their current setup still apparently include a single "identity server".

Re: Opmsg – A GPG Alternative

#27

Post by phicoh »

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…

I think that one of the really bad problems with gpg and openssl is that for a long time there was effectively only one implementation.

So the key thing for matrix is to create a healthy ecosystem that has multiple implementations of the protocol and make sure that the protocol can actually evolve.

Note that the 'identity server' is an optional component. As long as you stick to matrix native user IDs, there is no need to use one.

Re: Opmsg – A GPG Alternative

#28

Post by phicoh »

zaarn wrote: post #18
wongarsu wrote: post #15

Earlier quoted context omitted.

>It implements RSA, which nobody should be using anymore Can someone elaborate a bit? My impression was that RSA is fine with long keys, elliptic curves mainly provide shorter keys, and no decent quantum resistant algorithm emerged?

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, the big problem with RSA, is that is seems simple enough that people try to implement it themselves and get it wrong. With EC, you basically have to use one of the standard libraries.

Re: Opmsg – A GPG Alternative

#29

Post by tdj »

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…

This screenshot of an Ars Technica journalist with Phil Zimmerman, PGP author (yes, not the same as GPG), is very telling:

https://arstechnica.com/information-technology/2016/12/op-ed...

Re: Opmsg – A GPG Alternative

#30

Post by maxnoe »

cpach wrote: post #23
jively wrote: post #10

The reality of the situation is that you can't remove the human factor from security. So someone copying your email to someone else is a human problem that can't be fixed - someone could just as easily photograph the screen. The reality is email will continue to be used, and there is a use case for being able to send an email securely to another person. EFail was pretty bad, but only affected HTML email. Having a mod…

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?

Post reply on HN