>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.
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.
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.
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.
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.
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.
Only if someone out there is extracting, decompiling and auditing each version of the Signal iOS app in the app store. But I doubt anyone is doing this. If a backdoor is ever snuck into the signal ios app for a few users for a few weeks, I highly doubt anybody would notice.
Of course someone is doing this. I’m not sure they are the kind to tell it to the world, though.
Even “secure” softwares like Google Chrome can capture your whole browsing history if they suddenly decide to enable a flag on your IP address. No need for conspiracy or update, though Chrome is considered perfectly secure.
In Android you can also distribute updates to specific e-mail addresses, which is very convenient.
Yes but this requires the user to opt-in, you can't do it silently:
> After clicking the opt-in link, your testers will get an explanation of what it means to be a tester and a link to opt in. Each tester needs to opt in using the link.
Source: https://support.google.com/googleplay/android-developer/answ...
As for the Chrome thing, I'm a Firefox user but I would be surprised if it shipped with the option to remotely upload whole history without user's knowledge or consent, do you have a source to back that up?
So if a Signal group is using group invite links they have the same problem Skiff does.
What I would like to exist is something like Subresource Integrity [1] but for a URL itself, so that you could include a hash in a URL and let the browser warn you if the page source doesn't match the hash.
1. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Meta has done some work along with Cloudflare on this for WhatsApp Web, specifically. In general, JS crypto is always going to be suspect if the threat model involves distrusting the server (like in e2ee protocols like Signal).
Regardless of all this, your open source crypto library doesn't even use the Web Crypto APIs at all, but rather the dreaded js based crypto you are badmouthing (tweetnacl, stablelib)
One similarity between Lavabit and Skiff is that tptacek calls them both non-end-to-end encrypted.
One never has access to user private keys (Skiff).
And that had complied previously with US government subpoenas to provide metadata and data for users?
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....
Interesting. Link? Are you talking about this article? https://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits...
It seems to be talking about metadata, not data.
As a simple demonstration, even if client side code is perfectly secure, an adversary with server control can simply log all emails passing through the server and instantly have access to all new user emails that way. This means users have to trust the server, contradicting any notion of E2EE.
This are just old technical problems which are already solved, for example by Tutanota. Mails are not send in plaintext if they are encrypted, and mailbox can be encrypted too. Plaintext version of your data exist only in the memory of your computer while the session for your mail client is open.
What it comes to the search - it does not matter anymore. We have enough computational power these days and storage to hold emails on devices. User experience is about the same. Increasingly, it is just optimisation problem which can be done right. Just don’t use Electron for your email app.
But that is true that if you use skiff to send message for someone, who is not using skiff, the message is unencrypted because receiver has no means to decrypt it.
That is standrdisation issue. Apparantly PGP is not considered good enough.
But if we had standards, we have techology to provide E2EE emails.
Somehow the infrastructure should be transparent so that outsider can verify indeed at any time, that you don't collect logs from that traffic, or have no other means to inspect traffic if you want to.
There are currently no other means than just to use E2E encryption.
There is also another almost there, but that would mean that you should open-source your whole infrastructure, and use reproducible builds. Somehow there should be way to get access for outsiders, that you indeed use your infrastructure as you describe in your source code. But this is very complicated and also changeable at any time, unlike E2EE.
Apparently, email may not their main e2ee usecase. The CEO at Skiff wrote this on PrivacyGuides forums:
Our solution for external sharing was not intended for email. It is much more powerful to share E2EE real-time collaborative docs/files with subpages, embedded E2EE files, and so much more. It’s both confusing and frustrating to require that we implement a less powerful, worse experience that was never part of the original spec.
Also, pentest ≠ audit. Completely different!
Your transparency statement clearly says that Security audits. This is different than privacy audits. You cannot audit privacy, since you can intentionally change the functionality of your software right after the audit.
For the same reason, you cannot share open-source version of your software and say that it respects privacy. That can be only said if you use reproducible builds, and for client software only.
Both security audits and sharing your software as open, is about security, not the privacy. Open-source software and security audits help to reduce unintentional issues. And in this context it means a lot.
No. That is not what security audits are. Security audits ensure that software does safely what you, as service orderer claim, in a single moment. Usually including checklist.
But they cannot guarantee that you don’t change software between audits.
That is why E2EE exists as then it does not matter and we don’t need to trust.
Open-source, security audited client for E2EE communication with reproducible builds is the magical, correct combination to ensure both security and privacy.
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.