7 ms·

Founding engineer at Skiff here. >From the white paper, it appears as if this system requires its users to trust the server. That's not end-to-end encryption.

Founding engineer at Skiff here. >From the white paper, it appears as if this system requires its users to trust the server. That's not end-to-end encryption. What do I have wrong here? It doesn't. All data is encrypted client side across all apps - Skiff Mail, Drive, Pages, and Calendar. For sending external, the whitepaper is very clear how this case is handled in section 8.2 as securely as possible (without having PGP in place. Though this is something we are looking at based on community feedback). >Further, it looks like the email encryption provided by this system only works between users of Skiff. At that point, why use email at all? Why not use a real secure messenger? Instead of building an "encrypted email service", you could literally just build an email-flavored frontend to Matrix; either way, you're proxying to SMTP, not speaking it directly. Lots of folks are sick of getting sold their data sold based on their email. Even corporations are sick of largely giving more information about their customers to Google even notoriously Amazon that stopped sending purchase receipts via email. So even if not end to end encrypted, we do encrypt the emails with the recipient's keys ensuring that only the recipient can access this data. This is a strong privacy guarantee not just backed by a flimsy privacy policy but actual cryptography.

tptacek 3y ago
Section 8.2 seems to talk about how you send plaintext email via SMTP to users who aren't using Skiff. But that's not what I'm talking about with respect to end-to-end encryption. The white paper refers repeatedly to "browser" users. Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it? I'm still not clear why you designed a new, simplistic cryptosystem at all here; can't you do everything you're trying to do here on top of Matrix? Again: the cryptography promises you're making only work between users of your system.
- bastawhiz 3y ago
  > Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it? That's how literally any website works. How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data? You also trust Signal not to issue an update that sends data in plaintext over the network. Unless you're building an app from source, you implicitly trust the developer to some extent.
  - raggi 3y ago
    Signal doesn’t have a web client. Most of the stores it is distributed through have fairly strong resistance to compel orders.
    - dannyobrien 3y ago
      Yep, but Signal is still a potential adversary, and could roll out a backdoor. A couple of things that are easier in a web-delivered tool is deliver a backdoor to a user or group of users (which Skiff can track), or deliver a backdoor over a particular window of time across many users to decrease the chance of detection. I know Skiff uses IPFS in some of parts of their solutions, and there's something they could do with that for the first -- essentially making visiting a particular version of the code part of how it is accessed, but there's some real UI challenges, which maybe they're looking into (it's been a while since I checked them out: they have some great UX in other parts of their suite). The other tactic I've seen is to bundle the page into a browser extension, which moves you closer to Signal's status.
      - tptacek 3y ago
        Signal's servers can't backdoor the Signal Client. From what I understand of Skiff, Skiff's servers are the client.
        josephg 3y ago
        Not directly. They would have to roll out an update with the backdoor to the App Store. But as a user I’d be none the wiser. I wish there was some way on iOS to prove that some particular version of an app was built from a certain git hash. That way these sort of attacks would be easier to detect.
        progbits 3y ago
        That would be ideal. F-Droid on android can do this: https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ However there is still one advantage of even appstor: They have to push the backdoored version to everyone (or large set of users). So that drastically increases risk of being caught. Website under their control can backdoor one specific user or even just one session, making detection harder.
- amilich 3y ago
  It would be far more illogical to warp Matrix into an end-to-end encrypted calendar, note-taking product, file storage product, and email platform.
  - tptacek 3y ago
    Why? You'd use Matrix to distribute keys for encrypted blobs. That's how systems like these work anyways.
- Thorrez 3y ago
  What do you think of Lavabit? I think they operated in the same way, but the US government forced them out of business for refusing to hand over their TLS keys to allow the US to spy on Snowden. https://en.wikipedia.org/wiki/Lavabit https://en.wikipedia.org/wiki/Lavabit
  - akerl_ 3y ago
    Lavabit is the one that used user passwords to encrypt the messages, thus ensuring that they had access to all the necessary secrets to decrypt user messages any time the user was viewing them? And that had complied previously with US government subpoenas to provide metadata and data for users?
    - Thorrez 3y ago
      >And that had complied previously with US government subpoenas to provide metadata and data for users? Interesting. Link? Are you talking about this article? https://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits-ladar-levison-if-you-knew-what-i-know-about-email-you-might-not-use-it/?sh=68aaf258648a https://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits... It seems to be talking about metadata, not data.
    - amilich 3y ago
      +1
      - tptacek 3y ago
        Isn't that what you're Skiff is doing too? It seems like it's just the Lavabit design with a some 2010 cryptography layered on top.
        wishywashy0 3y ago
        No. Lavabit had fundamental flaws where passwords were sent to the server so anyone who could decrypt the HTTPS traffic could basically access the content [1]. Skiff's password mechanism actually solves this flaw cryptographically using known, established primitives. We use argon2id to take password and turn it into two cryptographic keys. One key is used for an SRP scheme to prove you have the password in a signing flow that bootstraps session management. The other key is actually the data encryption key. These keys are never sent to Skiff's servers and this generation happens all in the browser. Lavabit really failed fundamentally in having actual end to end encryption because the password was sent to the server. [1] https://arstechnica.com/information-technology/2013/11/op-ed-a-critique-of-lavabit/#:~:text=At%20account%20creation%20time%2C%20the,stored%20it%20on%20the%20server https://arstechnica.com/information-technology/2013/11/op-ed....
onereplyac 3y ago
It really is not backed by cryptographic security at all. Since your server has access to plaintext emails when sending and recieving (99.99999% of email addresses would be outside skiff), which completely subverts the whole point of encryption. A vulnerability on the server could leak all user emails, without needing their keys.... This is a solution theoretically only as strong as encryption at rest.
- i_play_stax 3y ago
  Bro, did we read the same comment? The encryption is handled client side; the cyphertext is the only thing the server sees.
  - onereplyac 3y ago
    The encryption happens after the server recieves the plaintext email and passes it to the client...
    - amilich 3y ago
      No, this is done with public-key encryption which does not require the client.
      - onereplyac2 3y ago
        Again, only between users with skiff emails, which is a negligible portion of all emails. This needs to be made clear as it is very misleading to the average user who probably thinks all emails are end to end encrypted.
        amilich 3y ago
        No: Skiff does not have access to a single email stored on our platform, including ones received externally. All are public-key encrypted, including subjects and content.
mgraczyk 3y ago
Worth noting that Google does not do what you're describing. Google has never literally "sold" data from Gmail and stopped using it for their own ads ~6 years ago.
- ginsbergjason 3y ago
  So gmail was making money off of personal emails as recently 2017. Why trust them? There is no good reason they shouldn’t e2ee that data.
  - onereplyac 3y ago
    Except there is a reason. Encrypting email has very little to no benefit, since it is transmitted in plaintext and usually stored in plaintext on the recipient's side, your emails almost always exist in unencrypted form. On top of that it has major usability drawbacks, for example you cant ask the server to search emails for you anymore - all emails have to be downloaded on all your devices to be able to search - which is what skiff does. It will be okay at the start, and progressively get slower and use more space on your drive the more you use it.
    - em-bee 3y ago
      i have 2.5 million emails in a 32GB datastore. no mailprovider is going to allow me to store that much mail, and search is actually quite fast. if it isn't for you, then get a better mail client.
      - mgraczyk 3y ago
        Google's cheapest paid plan ($6/month) gives you 30GB. The $12/month plan is 2TB of storage. I currently have over 30GB of email in Gmail and everything works fine.
        mediumsmart 3y ago
        I have around 17GB of pop3fetchallnokeep in the mail folder and the backup is somewhere in the btreeflatfile heap in that UtahDataCenter free of charge training darkgpt 5.8

tptacek 3y ago

Section 8.2 seems to talk about how you send plaintext email via SMTP to users who aren't using Skiff. But that's not what I'm talking about with respect to end-to-end encryption. The white paper refers repeatedly to "browser" users. Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it? I'm still not clear why you designed a new, simplistic cryptosystem at all here; can't you do everything you're trying to do here on top of Matrix? Again: the cryptography promises you're making only work between users of your system.

bastawhiz 3y ago
> Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it? That's how literally any website works. How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data? You also trust Signal not to issue an update that sends data in plaintext over the network. Unless you're building an app from source, you implicitly trust the developer to some extent.
- raggi 3y ago
  Signal doesn’t have a web client. Most of the stores it is distributed through have fairly strong resistance to compel orders.
  - dannyobrien 3y ago
    Yep, but Signal is still a potential adversary, and could roll out a backdoor. A couple of things that are easier in a web-delivered tool is deliver a backdoor to a user or group of users (which Skiff can track), or deliver a backdoor over a particular window of time across many users to decrease the chance of detection. I know Skiff uses IPFS in some of parts of their solutions, and there's something they could do with that for the first -- essentially making visiting a particular version of the code part of how it is accessed, but there's some real UI challenges, which maybe they're looking into (it's been a while since I checked them out: they have some great UX in other parts of their suite). The other tactic I've seen is to bundle the page into a browser extension, which moves you closer to Signal's status.
    - tptacek 3y ago
      Signal's servers can't backdoor the Signal Client. From what I understand of Skiff, Skiff's servers are the client.
      - josephg 3y ago
        Not directly. They would have to roll out an update with the backdoor to the App Store. But as a user I’d be none the wiser. I wish there was some way on iOS to prove that some particular version of an app was built from a certain git hash. That way these sort of attacks would be easier to detect.
        progbits 3y ago
        That would be ideal. F-Droid on android can do this: https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ However there is still one advantage of even appstor: They have to push the backdoored version to everyone (or large set of users). So that drastically increases risk of being caught. Website under their control can backdoor one specific user or even just one session, making detection harder.
amilich 3y ago
It would be far more illogical to warp Matrix into an end-to-end encrypted calendar, note-taking product, file storage product, and email platform.
- tptacek 3y ago
  Why? You'd use Matrix to distribute keys for encrypted blobs. That's how systems like these work anyways.
Thorrez 3y ago
What do you think of Lavabit? I think they operated in the same way, but the US government forced them out of business for refusing to hand over their TLS keys to allow the US to spy on Snowden. https://en.wikipedia.org/wiki/Lavabit https://en.wikipedia.org/wiki/Lavabit
- akerl_ 3y ago
  Lavabit is the one that used user passwords to encrypt the messages, thus ensuring that they had access to all the necessary secrets to decrypt user messages any time the user was viewing them? And that had complied previously with US government subpoenas to provide metadata and data for users?
  - Thorrez 3y ago
    >And that had complied previously with US government subpoenas to provide metadata and data for users? Interesting. Link? Are you talking about this article? https://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits-ladar-levison-if-you-knew-what-i-know-about-email-you-might-not-use-it/?sh=68aaf258648a https://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits... It seems to be talking about metadata, not data.
  - amilich 3y ago
    +1
    - tptacek 3y ago
      Isn't that what you're Skiff is doing too? It seems like it's just the Lavabit design with a some 2010 cryptography layered on top.
      - wishywashy0 3y ago
        No. Lavabit had fundamental flaws where passwords were sent to the server so anyone who could decrypt the HTTPS traffic could basically access the content [1]. Skiff's password mechanism actually solves this flaw cryptographically using known, established primitives. We use argon2id to take password and turn it into two cryptographic keys. One key is used for an SRP scheme to prove you have the password in a signing flow that bootstraps session management. The other key is actually the data encryption key. These keys are never sent to Skiff's servers and this generation happens all in the browser. Lavabit really failed fundamentally in having actual end to end encryption because the password was sent to the server. [1] https://arstechnica.com/information-technology/2013/11/op-ed-a-critique-of-lavabit/#:~:text=At%20account%20creation%20time%2C%20the,stored%20it%20on%20the%20server https://arstechnica.com/information-technology/2013/11/op-ed....

onereplyac 3y ago

It really is not backed by cryptographic security at all. Since your server has access to plaintext emails when sending and recieving (99.99999% of email addresses would be outside skiff), which completely subverts the whole point of encryption. A vulnerability on the server could leak all user emails, without needing their keys.... This is a solution theoretically only as strong as encryption at rest.

i_play_stax 3y ago
Bro, did we read the same comment? The encryption is handled client side; the cyphertext is the only thing the server sees.
- onereplyac 3y ago
  The encryption happens after the server recieves the plaintext email and passes it to the client...
  - amilich 3y ago
    No, this is done with public-key encryption which does not require the client.
    - onereplyac2 3y ago
      Again, only between users with skiff emails, which is a negligible portion of all emails. This needs to be made clear as it is very misleading to the average user who probably thinks all emails are end to end encrypted.
      - amilich 3y ago
        No: Skiff does not have access to a single email stored on our platform, including ones received externally. All are public-key encrypted, including subjects and content.

mgraczyk 3y ago

Worth noting that Google does not do what you're describing. Google has never literally "sold" data from Gmail and stopped using it for their own ads ~6 years ago.

ginsbergjason 3y ago
So gmail was making money off of personal emails as recently 2017. Why trust them? There is no good reason they shouldn’t e2ee that data.
- onereplyac 3y ago
  Except there is a reason. Encrypting email has very little to no benefit, since it is transmitted in plaintext and usually stored in plaintext on the recipient's side, your emails almost always exist in unencrypted form. On top of that it has major usability drawbacks, for example you cant ask the server to search emails for you anymore - all emails have to be downloaded on all your devices to be able to search - which is what skiff does. It will be okay at the start, and progressively get slower and use more space on your drive the more you use it.
  - em-bee 3y ago
    i have 2.5 million emails in a 32GB datastore. no mailprovider is going to allow me to store that much mail, and search is actually quite fast. if it isn't for you, then get a better mail client.
    - mgraczyk 3y ago
      Google's cheapest paid plan ($6/month) gives you 30GB. The $12/month plan is 2TB of storage. I currently have over 30GB of email in Gmail and everything works fine.
      - mediumsmart 3y ago
        I have around 17GB of pop3fetchallnokeep in the mail folder and the backup is somewhere in the btreeflatfile heap in that UtahDataCenter free of charge training darkgpt 5.8