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.

techraf
  • 9,141
  • 11
  • 44
  • 62
Yurii
  • 463
  • 3
  • 11
  • 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 Aug 01 '16 at 08: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 Aug 01 '16 at 09: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 Aug 01 '16 at 14:33
  • See https://security.stackexchange.com/questions/139596/signal-protocol-implementations-pub-key-authentication-and-inspectability-all for some interesting reading on how Signal solves the problem of users authenticating other users' public keys, using 'Safey Numbers'. – mti2935 May 11 '22 at 14:45

2 Answers2

12

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.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
RLFP
  • 617
  • 5
  • 15
  • But why Alice cannot encrypt the message for Bob by Bob's key in the first place? – Yurii Aug 01 '16 at 08: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 Aug 01 '16 at 08: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 Aug 01 '16 at 08:43
  • No, the key you receive is your own. That happens on the browser and is stored locally. The distribution of public keys of other users is the issue here. If you accept that the public key you receive from ProtonMail belong to Bob (you being Alice), then you accept ProtonMail as trusted third party, which gives them a chance to abuse/assume the identity of Bob on the first communication instance. – RLFP Aug 01 '16 at 08:46
  • Still, same attack may be taken: you receive some fresh key instead of Bob's actual one. Then you message could be decrypted on server side, but neither you (Alice), neither Bob could notice that - because Bob will receive reencrypted message, this time with his actual key. – Yurii Aug 01 '16 at 08:51
  • 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 Aug 01 '16 at 08:53
  • The article mentions "in addition to Bob's" not instead of Bob's. – techraf Aug 01 '16 at 08:56
  • I just thought that you don't generate a new public key for yourself each time, but that reuse it after initially generated. But then I figured out it is impossible without storing private key on the server (and with ProtonMail you don't store it locally either). – Yurii Aug 01 '16 at 08:58
  • 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 Aug 01 '16 at 09: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.

Bruno Rohée
  • 5,221
  • 28
  • 39
munchkin
  • 27
  • 2