Neither the app developer, nor me (the platform) will be able to see any user data. (Same as what @1Password does.) This also means automatic GDPR compliance for the app developer. I'll share a lot more technical and business details in a few days. I'll also open source it. 
-
Show this thread
-
Here's the mailing list if you want to keep up to date. No more than 1 to 2 emails a month. https://updates.encrypted.dev/subscribe
pic.twitter.com/eJfW7CDX5E
2 replies 2 retweets 30 likesShow this thread -
Some more details: The platform will offer 3 core services:
Account Management
Database
File Store
All these will be available through a JavaScript API for the browser. Initial iOS and Android support will be through @reactnative.2 replies 0 retweets 10 likesShow this thread -
A user signup generates an asymmetric key pair in the browser. The public key gets sent to the platform along with the username & password. The private key gets stored in the browser’s local storage and downloaded to be put somewhere safe, or printed as a QR code.
3 replies 1 retweet 5 likesShow this thread -
User authentication happens through a process similar to passwordless ssh: The platform encrypts a random message with the user’s public key that only the holder of the private key can decrypt. The decrypted message gets sent to the platform, and a match authenticates the user.
2 replies 0 retweets 4 likesShow this thread -
Replying to @dvassallo
PAKE would be better overall, but if you want to use an asymmetric key directly, signing is far far better for this case than encryption.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
When you say PAKE is better, is that just performance? Or better security or UX? I’ll look more into it. Thanks. PS. I was only thinking of encrypting a challenge message once during the WebSocket setup (upon user login). Then that connection stays authenticated.
1 reply 0 retweets 0 likes -
Replying to @dvassallo
PAKE is a ZKP scheme that starts with their password, which is where real-world users will begin, so it just tends to remove layers and can be portable without having to export/import keys. Implementing auth as encrypting a challenge is a classic cryptographic design mistake.
1 reply 0 retweets 0 likes -
Replying to @colmmacc @dvassallo
It tends to expose the encrypted to arbitrary (i.e. large sizes) and malicious (i.e. padding oracles) inputs. Signing is specifically designed for proof of key possession and has a lot of thought through defenses.
1 reply 0 retweets 0 likes -
Replying to @colmmacc @dvassallo
Usual pattern is to establish a channel with DH, and to sign the DH shares. Gives you forward secrecy and proof of key. Asymmetric key encryption isn't used in modern network encryption. Ok-ish for durable data envelope encryption.
1 reply 0 retweets 0 likes
For the sharing encrypted data, DBs or channels, that's an open hard problem. If you share the underlying encryption key, it has to be bulk-reencrypted on revoke. If you do pair-wise, you have to denormalize and can end up with N^2 key establishment problems.
-
-
Replying to @colmmacc
That’s great info! Thanks! Once I have a naive POC, I’ll seek help from experts about all this. About sharing and key revocation, yes there will have to be some inconvenience for the users, and will require everyone to get the new key and re-login.
@1Password does that too.0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.