5 ms·

What does UX\UI has to do with E2EE? Sure, Telegram team used more human resources elsewhere while WA and Signal where doing their E2EE magic, but once they wh

by konart 5y ago

What does UX\UI has to do with E2EE? Sure, Telegram team used more human resources elsewhere while WA and Signal where doing their E2EE magic, but once they where done - what stopped them from investing into everything else?

smt88 5y ago
Zero-knowledge E2EE makes it difficult or impossible to implement certain "quality of life" features that users have come to expect from cloud-based services. The most salient of these is that, if you lose your keys, you may never be able to recover your data.
Andrew_nenakhov 5y ago
If you have true e2ee, you can't enter your login/password and see all your chats right there, instantly.
- piaste 5y ago
  Are you sure? You can do what good password managers do: - Hash the password client-side - Send the hash to the server. The server treats it as a password, and gives you your blob of encrypted data - Decrypt the data client-side using the original password
  - Andrew_nenakhov 5y ago
    That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages. Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.
    - piaste 5y ago
      > That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages. That's a different, further goalpost - we were talking about E2E encryption, weren't we? I.e. the server should not need to decrypt your data to provide it. Obviously if you want to be able to recover your history from storage with just a password, that does mean the password is the only protection over that history, tautology. So storing your history should be optional, if you're seriously worried about brute-force attacks on data encrypted at rest (indeed, even WhatsApp makes it optional to have a backup of your data!). In any case, that doesn't compromise future secrecy - i.e. gaining access to the history still doesn't give you access to future messages. > Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'. Off the top of my head, it doesn't have to be a single blob for all your data. You could split the blob into tiny equal-sized chunks, and then have a separate encrypted index file which stores the information of which chunks hold which chats (plus just enough metadata, e.g. chat titles and last messages, to display your homepage properly). The index file is the only one downloaded on first login, then when you want to open a chat it moves the corresponding chunks to the top of the download list.
      - Andrew_nenakhov 5y ago
        > we were talking about E2E encryption, weren't we? Exactly, and what is described is not e2ee at all.
        piaste 5y ago
        How is it not E2EE? Are you going by a stricter definition than commonly used? > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. [..] End-to-end encryption is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves. Which requirement do you believe is failed by such a system?
- gefhfffh 5y ago
  This is wrong, see Element/Matrix, which practically does that
  - Andrew_nenakhov 5y ago
    Ok. After all, what do I know about encryption? I only directed the development of communication products that had OTR, OMEMO and PGP/GPG encryption in them. Please, enlighten me how exactly Element/Matrix practically do that. Thank you in advance.
    - gefhfffh 5y ago
      It backups your keys encrypted with a password only you know at server side (opt in) When you login, you provide that password, and Element can use that to decrypt the keys and use these to decrypt the messages stored in the cloud Alternatively, you can solely rely on syncing keys between verified devices.
      - Andrew_nenakhov 5y ago
        That is not 'true e2ee' at all, and more of a security theater.
        gefhfffh 5y ago
        How is that? Only you as a recipient can decrypt the messages, because they are sent e2ee to you. And this stays true if you use the backup, as only you know that password.
        Andrew_nenakhov 5y ago
        Encrypted backups are just that, encrypted backups. They are called end-to-end encrypted backups only by people who are ignorant of correct terminology. Even the Wikipedia entry on e2ee addresses this. Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols. But then again, most users do not need real security, they are fine with a warm comforting feeling of safety, provided by a sincere promise that everything is really safe, as demonstrated by Telegram users.
hutzlibu 5y ago
On signal you will get various security related messages, like person x changed is key (because they reinstalled). That stuff confuses every non IT person. Not caring about it, allows for a more simple UI and UX to provide a easy way for person A to message B. Where B can be a group of thousands of people. (a really secure way of posting a message to a big group would be way more complicated, even signal makes compromises)

by konart 5y ago

smt88 5y ago

Zero-knowledge E2EE makes it difficult or impossible to implement certain "quality of life" features that users have come to expect from cloud-based services. The most salient of these is that, if you lose your keys, you may never be able to recover your data.

Andrew_nenakhov 5y ago

If you have true e2ee, you can't enter your login/password and see all your chats right there, instantly.

piaste 5y ago
Are you sure? You can do what good password managers do: - Hash the password client-side - Send the hash to the server. The server treats it as a password, and gives you your blob of encrypted data - Decrypt the data client-side using the original password
- Andrew_nenakhov 5y ago
  That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages. Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.
  - piaste 5y ago
    > That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages. That's a different, further goalpost - we were talking about E2E encryption, weren't we? I.e. the server should not need to decrypt your data to provide it. Obviously if you want to be able to recover your history from storage with just a password, that does mean the password is the only protection over that history, tautology. So storing your history should be optional, if you're seriously worried about brute-force attacks on data encrypted at rest (indeed, even WhatsApp makes it optional to have a backup of your data!). In any case, that doesn't compromise future secrecy - i.e. gaining access to the history still doesn't give you access to future messages. > Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'. Off the top of my head, it doesn't have to be a single blob for all your data. You could split the blob into tiny equal-sized chunks, and then have a separate encrypted index file which stores the information of which chunks hold which chats (plus just enough metadata, e.g. chat titles and last messages, to display your homepage properly). The index file is the only one downloaded on first login, then when you want to open a chat it moves the corresponding chunks to the top of the download list.
    - Andrew_nenakhov 5y ago
      > we were talking about E2E encryption, weren't we? Exactly, and what is described is not e2ee at all.
      - piaste 5y ago
        How is it not E2EE? Are you going by a stricter definition than commonly used? > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. [..] End-to-end encryption is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves. Which requirement do you believe is failed by such a system?
gefhfffh 5y ago
This is wrong, see Element/Matrix, which practically does that
- Andrew_nenakhov 5y ago
  Ok. After all, what do I know about encryption? I only directed the development of communication products that had OTR, OMEMO and PGP/GPG encryption in them. Please, enlighten me how exactly Element/Matrix practically do that. Thank you in advance.
  - gefhfffh 5y ago
    It backups your keys encrypted with a password only you know at server side (opt in) When you login, you provide that password, and Element can use that to decrypt the keys and use these to decrypt the messages stored in the cloud Alternatively, you can solely rely on syncing keys between verified devices.
    - Andrew_nenakhov 5y ago
      That is not 'true e2ee' at all, and more of a security theater.
      - gefhfffh 5y ago
        How is that? Only you as a recipient can decrypt the messages, because they are sent e2ee to you. And this stays true if you use the backup, as only you know that password.
        Andrew_nenakhov 5y ago
        Encrypted backups are just that, encrypted backups. They are called end-to-end encrypted backups only by people who are ignorant of correct terminology. Even the Wikipedia entry on e2ee addresses this. Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols. But then again, most users do not need real security, they are fine with a warm comforting feeling of safety, provided by a sincere promise that everything is really safe, as demonstrated by Telegram users.

hutzlibu 5y ago

On signal you will get various security related messages, like person x changed is key (because they reinstalled). That stuff confuses every non IT person. Not caring about it, allows for a more simple UI and UX to provide a easy way for person A to message B. Where B can be a group of thousands of people. (a really secure way of posting a message to a big group would be way more complicated, even signal makes compromises)