12

Currently I'm reading an article about ProtonMail here and I don't understand it.

Now let’s address ProtonMail’s weaknesses. One of the big issues is that it isn’t easy to know whether a message sent to another ProtonMail user is being encrypted to the recipient’s correct public key, which is stored on ProtonMail’s keyserver. For example, if Alice sends Bob a message encrypted to his public key, it’s harder for anyone else to read the message. But since ProtonMail distributes the encryption keys to users, it has the technical ability to give Alice its own keys in addition to Bob’s, thus encrypting the messages in a way that would allow it to eavesdrop.

What is meant under 'its own keys'? You encrypt messages using public keys only and they are, well, public. So where is the problem in fact that someone knows someone elses public key?

UPDATE After comments and answer I realized that confusion goes away if you reword the highlighted sentence like this:

But since ProtonMail distributes the encryption keys to users, it has the technical ability to give Alice freshly generated malicious keys instead of Bob’s, thus encrypting the messages in a way that would allow it to decrypt them on the server (using private key from freshly generated keys) even without knowing Bob's private key.

Improve this question
4
  • 1
    The sentence reads "its own keys in addition to Bob’s". ProtonMail uses public-key cryptography to encrypt the message, so the only thing that I can get from this is a suggestion that they are able to make client silently BCC the email to themselves.
    – techraf
    Commented Aug 1, 2016 at 8:55
  • 7
    The sentences rather confusing. What it means is : Because Protonmail is the middle-man, it can do anything in between. E.g. when Bob ask Protonmail about Alice public key, the server can indeed send its own public key instead of Alice public key. When Bob send mail using the public key to Protonmail server, the server can decrypt it (thus eavesdrop the content), then re-encrypt it with Alice public key and send to Alice. Alice won't even known Protonmail give Bob other public key.
    – mootmoot
    Commented Aug 1, 2016 at 9:05
  • 1
    By the way: to me this seems a BS article. In the sense that ProtonMail never said that their protocol guarantees the correct distribution of the keys in the first place. It's like the KeePass thing: "Oh, KeePass is vulnerable to keyloggers!" Well, yes that's because it is not meant to be invulnerable to that kind of attack. It's a threat outside the threat model. If you are serious about encryption and authentication you already know that the public key must be exchanged in person or via a mathematically sound key-sharing scheme and not through any 3rd party...
    – Bakuriu
    Commented Aug 1, 2016 at 14:33
  • See security.stackexchange.com/questions/139596/… for some interesting reading on how Signal solves the problem of users authenticating other users' public keys, using 'Safey Numbers'.
    – mti2935
    Commented May 11, 2022 at 14:45

2 Answers 2

Reset to default
12
+50

This is mostly a guess on what they mean:

Well, Public key schemes need the trusted third party. In this case ProtonMail is assumed to be the third party, who - the first time Alice and Bob communicate - give Alice a public key owned by themselves. When Alice then send mails to Bob ProtonMail decrypts the mail and encrypts it with Bob's key, but keeps the unencrypted mail for themselves. So as the article states:

ProtonMail does allow you to export your public key and send it to another person, but you can’t easily confirm whether your ProtonMail messages are being sent to the same key. It would take serious tech chops to verify the key.

You could send the public key to the recipient beforehand, but they then must trust that it is you sending it.

Improve this answer
9
  • But why Alice cannot encrypt the message for Bob by Bob's key in the first place?
    – Yurii
    Commented Aug 1, 2016 at 8:38
  • 3
    Alice could! But that is provided that she knows Bobs public key. ProtonMail also distributes the public keys - AFAIK - so she would have to trust the third party, who in this case would be ProtonMail.
    – RLFP
    Commented Aug 1, 2016 at 8:41
  • 5
    So the main problem is that you could receive malicious public key, that is not actually yours, but was freshly generated by ProtonMail (e. g. by the order from government). Then they could easily decrypt your message.
    – Yurii
    Commented Aug 1, 2016 at 8:43
  • 1
    That was the idea. But you as a user generate the key on you own browser, so you control the key being generated. The distribution of said key is a different matter.
    – RLFP
    Commented Aug 1, 2016 at 8:53
  • 5
    @Yurii : Letting a third party act as public key distributors is a bad idea. Even the admin are not doing anything evil, if the server are hacked, the bad guy can inject its own public key to whoever request it.
    – mootmoot
    Commented Aug 1, 2016 at 9:12
1

Again it all depends on the web of trust model. Unless you meet your end point face to face, you'll have to depend on third party corroboration of identity. Even a Diffie-Hellman key exchange is pointless if the man in the middle brokers the key exchange and you don't have the ability to check the signature out of band.

In this case, you won't be able to determine receipt of the message or multi copies of its existence.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .