8 ms·

This announcement is an example of why I am not using ProtonMail anymore. There are a lot of things they do that sound very good on marketing materials, but upo

This announcement is an example of why I am not using ProtonMail anymore. There are a lot of things they do that sound very good on marketing materials, but upon examination are security theater. For example, they claim, "We have chosen a particular elliptic curve system known as X25519, which is fast, secure, and particularly resistant to timing attacks. It’s simple to implement". However, previously they've said that they use Indutny's library [0]. This library is somewhat infamous because its leadership deciding to discard any pretense of defending against timing attacks on the grounds that would make the library "too slow." [1] There are other options. They could have used something with good timing attack resistance from WebCrypto. Those options exist. Folks with more skill than I have recommended P-256 as an option. [0]: https://protonmail.com/blog/openpgpjs-3-release/ https://protonmail.com/blog/openpgpjs-3-release/ [1]: https://github.com/indutny/elliptic/issues/128#issuecomment-302593662 https://github.com/indutny/elliptic/issues/128#issuecomment-...

anfedorov 8y ago
Worth noting, in similar vein — https://protonvpn.com/support/macos-ikev2-vpn-setup/ https://protonvpn.com/support/macos-ikev2-vpn-setup/
- KirinDave 8y ago
  I don't know OSX very well these days. Is that... is that actually installing a new global SSL trust root? Doesn't that mean ProtonMail now can seamlessly MitM all SSL connections on that machine? Please tell me I'm reading that wrong, because I don't recall doing this for ProtonVPN on linux.
  - deagle50 8y ago
    In the instructions they ask the user to "always trust" the cert for all use cases, including SSL. If you do that, any app that uses OS certs can be MITMed. It should be enough to trust the cert for IPSec only.
    - TimTheTinker 8y ago
      My knowledge is limited in crypto, but I'm pretty sure you should never trust a root cert (even for "IPSec only") unless it carries responsibility and public scrutiny equal to or greater than a standard CA. (Unless it's the owner of the device [including you] or a close associate you trust.)
    - protonmail 8y ago
      Indeed, it is enough to trust the cert just for IPSec, and we have updated the article to reflect that. We also have native applications on macOS so the manual IKEv2 setup is not the recommend method of usage of ProtonVPN.
      - deagle50 8y ago
        Cheers!
arghwhat 8y ago
NIST curves like P-256 is generally not considered trustworthy, which is why the general consensus is to use Ed25519 for any elliptic curve cryptography. Using Ed25519 is by popular opinion the right choice. However, the concern about their use of indutny's library and the comment you link to is entirely separate. Choosing to have timing attacks for performance in a cryptographic library seems absolutely absurd, and if this is still the case (the comment is from 2017), then that library should be avoided at all cost.
- KirinDave 8y ago
  I have found no evidence that the author has changed their stance on this issue. You can find other issues that have also been closed with a brief explanation. If the author wants to show up and say otherwise, I'm happy to take correction. But, I'd rather have a robust implementation of a speculatively less secure scheme then have the undelivered promise of a more secure scheme papering over an insecure implementation.
- tptacek 8y ago
  That is not at all the case. P-256 is widely used and no cryptographer seriously believes there's anything "untrustworthy" about it. Rather, the problem with P-256 is that it's easy to misuse, like most curves. It's hard to implement in constant time and the NIST P-curves generally lend themselves to invalid curve attacks, which need to be guarded against. Curve25519 avoids these problems. But then, if you're using a naive Javascript library, you've thrown out one of the main benefits of Curve25519 already, and are left essentially with invalid curve attacks, which are not especially hard to defend against and not always even relevant to a given protocol (who could be bothered to go look at what OpenPGP.js is doing with them, I don't know). Ed25519 is the signing curve equivalent to Curve25519/X25519. It's what you'd use to generate and verify signature, but not what you'd use for ECDH.
  - arghwhat 8y ago
    I'm sorry, I misworded myself: There is general distrust in NIST, not any known issues with those curves. However, it is general consensus to prefer Ed25519 over NIST curves, specifically preferring it over P-256. The benefits of its implementation are a cherry on top. I have yet to see any suggestion or reason to pick P-256 when Ed25519 is available. And yes, Ed25519 is the defacto standard. Hell, I don't even recall the last time I heard P-256 mentioned. It surprises me every time I stumble upon it. Picking anything other than Ed25519 means deviating from the norm, which would normally cause worry. Granted, P-256 is fine, but there is absolutely no argument for claiming Ed25519 was the wrong choice of algorithm. And yes, I specifically refer to Ed25519 because it is the one relevant here. We're talking about signing, not key exchanges.
glaurung_ 8y ago
Out of curiosity, what did you switch to? I'd like to leave Gmail and Proton Mail seems to be pretty well recommended. Is Fast Mail a better option?
- rmdashrfstar 8y ago
  I've been using fastmail for 2 years and haven't had any problems with it, but I've no input on security or similar concerns.
- _eht 8y ago
  Fastmail is a great service, the caveat is that they are based in Australia. Take that for what it's worth.
  - wtmt 8y ago
    Fastmail the company is based in Australia, while Fastmail's servers are located in the US. Take that for what it's worth, considering Five Eyes!
    - _eht 8y ago
      That’s a double whammy IMO
- KirinDave 8y ago
  I use Gmail for most things, because in terms of account security it's probably the best in the world. I do not use email for discussing sensitive topics. It is not the right tool for the job.
  - JudgeWapner 8y ago
    Does anyone use gmail + PGP ? if the two parties understand how to send encrypted messages over web clients, isn't that still secure ? I haven't heard much about PGP for the past 5+ years. I realize PGP itself isn't a protocol, but there used to be a system where you'd publish your public key (irrespective of what protocol (RSA, ECDSA, etc) you use) somewhere and anyone could send you encrypted messages and paste the base64 text into insecure clients.
storrgie 8y ago
what provider, or self hosted software do you suggest as alternative?
bogomipz 8y ago
>"There are a lot of things they do that sound very good on marketing materials, but upon examination are security theater." Indeed like still pushing the trope that since their datacenters are located in Switzerland they are able to provide more privacy protections. This is even mentioned on their homepage, and of course this hasn't been true in a few years now.[1] [1] https://www.bbc.com/news/world-europe-37465853 https://www.bbc.com/news/world-europe-37465853
bartbutler 8y ago
We are aware of the the issues brought up in [0] and [1]. As suggested in [2], we are already considering to switch to an implementation in WebAssembly to mitigate the possibility of timing attacks on the web platform. In our mobile and desktop apps, where timing attack resistance is easier to achieve, the X25519 implementation is already constant-time. Once they are generated, keys are controlled by our users and not easily updated, so we wanted to make our choice of default curve as future-proof as we could while balancing speed and interoperability. [0]: https://github.com/indutny/elliptic/issues/128 https://github.com/indutny/elliptic/issues/128 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861639#10 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861639#10 [2]: https://github.com/openpgpjs/openpgpjs/issues/720 https://github.com/openpgpjs/openpgpjs/issues/720

anfedorov 8y ago

Worth noting, in similar vein — https://protonvpn.com/support/macos-ikev2-vpn-setup/ https://protonvpn.com/support/macos-ikev2-vpn-setup/

KirinDave 8y ago
I don't know OSX very well these days. Is that... is that actually installing a new global SSL trust root? Doesn't that mean ProtonMail now can seamlessly MitM all SSL connections on that machine? Please tell me I'm reading that wrong, because I don't recall doing this for ProtonVPN on linux.
- deagle50 8y ago
  In the instructions they ask the user to "always trust" the cert for all use cases, including SSL. If you do that, any app that uses OS certs can be MITMed. It should be enough to trust the cert for IPSec only.
  - TimTheTinker 8y ago
    My knowledge is limited in crypto, but I'm pretty sure you should never trust a root cert (even for "IPSec only") unless it carries responsibility and public scrutiny equal to or greater than a standard CA. (Unless it's the owner of the device [including you] or a close associate you trust.)
  - protonmail 8y ago
    Indeed, it is enough to trust the cert just for IPSec, and we have updated the article to reflect that. We also have native applications on macOS so the manual IKEv2 setup is not the recommend method of usage of ProtonVPN.
    - deagle50 8y ago
      Cheers!

arghwhat 8y ago

NIST curves like P-256 is generally not considered trustworthy, which is why the general consensus is to use Ed25519 for any elliptic curve cryptography. Using Ed25519 is by popular opinion the right choice. However, the concern about their use of indutny's library and the comment you link to is entirely separate. Choosing to have timing attacks for performance in a cryptographic library seems absolutely absurd, and if this is still the case (the comment is from 2017), then that library should be avoided at all cost.

KirinDave 8y ago
I have found no evidence that the author has changed their stance on this issue. You can find other issues that have also been closed with a brief explanation. If the author wants to show up and say otherwise, I'm happy to take correction. But, I'd rather have a robust implementation of a speculatively less secure scheme then have the undelivered promise of a more secure scheme papering over an insecure implementation.
tptacek 8y ago
That is not at all the case. P-256 is widely used and no cryptographer seriously believes there's anything "untrustworthy" about it. Rather, the problem with P-256 is that it's easy to misuse, like most curves. It's hard to implement in constant time and the NIST P-curves generally lend themselves to invalid curve attacks, which need to be guarded against. Curve25519 avoids these problems. But then, if you're using a naive Javascript library, you've thrown out one of the main benefits of Curve25519 already, and are left essentially with invalid curve attacks, which are not especially hard to defend against and not always even relevant to a given protocol (who could be bothered to go look at what OpenPGP.js is doing with them, I don't know). Ed25519 is the signing curve equivalent to Curve25519/X25519. It's what you'd use to generate and verify signature, but not what you'd use for ECDH.
- arghwhat 8y ago
  I'm sorry, I misworded myself: There is general distrust in NIST, not any known issues with those curves. However, it is general consensus to prefer Ed25519 over NIST curves, specifically preferring it over P-256. The benefits of its implementation are a cherry on top. I have yet to see any suggestion or reason to pick P-256 when Ed25519 is available. And yes, Ed25519 is the defacto standard. Hell, I don't even recall the last time I heard P-256 mentioned. It surprises me every time I stumble upon it. Picking anything other than Ed25519 means deviating from the norm, which would normally cause worry. Granted, P-256 is fine, but there is absolutely no argument for claiming Ed25519 was the wrong choice of algorithm. And yes, I specifically refer to Ed25519 because it is the one relevant here. We're talking about signing, not key exchanges.

glaurung_ 8y ago

Out of curiosity, what did you switch to? I'd like to leave Gmail and Proton Mail seems to be pretty well recommended. Is Fast Mail a better option?

rmdashrfstar 8y ago
I've been using fastmail for 2 years and haven't had any problems with it, but I've no input on security or similar concerns.
_eht 8y ago
Fastmail is a great service, the caveat is that they are based in Australia. Take that for what it's worth.
- wtmt 8y ago
  Fastmail the company is based in Australia, while Fastmail's servers are located in the US. Take that for what it's worth, considering Five Eyes!
  - _eht 8y ago
    That’s a double whammy IMO
KirinDave 8y ago
I use Gmail for most things, because in terms of account security it's probably the best in the world. I do not use email for discussing sensitive topics. It is not the right tool for the job.
- JudgeWapner 8y ago
  Does anyone use gmail + PGP ? if the two parties understand how to send encrypted messages over web clients, isn't that still secure ? I haven't heard much about PGP for the past 5+ years. I realize PGP itself isn't a protocol, but there used to be a system where you'd publish your public key (irrespective of what protocol (RSA, ECDSA, etc) you use) somewhere and anyone could send you encrypted messages and paste the base64 text into insecure clients.

storrgie 8y ago

what provider, or self hosted software do you suggest as alternative?

bogomipz 8y ago

>"There are a lot of things they do that sound very good on marketing materials, but upon examination are security theater." Indeed like still pushing the trope that since their datacenters are located in Switzerland they are able to provide more privacy protections. This is even mentioned on their homepage, and of course this hasn't been true in a few years now.[1] [1] https://www.bbc.com/news/world-europe-37465853 https://www.bbc.com/news/world-europe-37465853

bartbutler 8y ago

We are aware of the the issues brought up in [0] and [1]. As suggested in [2], we are already considering to switch to an implementation in WebAssembly to mitigate the possibility of timing attacks on the web platform. In our mobile and desktop apps, where timing attack resistance is easier to achieve, the X25519 implementation is already constant-time. Once they are generated, keys are controlled by our users and not easily updated, so we wanted to make our choice of default curve as future-proof as we could while balancing speed and interoperability. [0]: https://github.com/indutny/elliptic/issues/128 https://github.com/indutny/elliptic/issues/128 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861639#10 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861639#10 [2]: https://github.com/openpgpjs/openpgpjs/issues/720 https://github.com/openpgpjs/openpgpjs/issues/720