> OH, so you want a way for the server to encrypt data just for a given client, that they can't read.
No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem.
Please, make this pain stop. Why does this thread never go anywhere clear & always goes to misinformation?
I really don't think Nitrokey made everything crystal clear, but it's far far less confusing than where we are right now after this brand new vast massive tragic & sorrowful retrogression in the discussion, so,
> While FIDO is supported by web browsers, using Nitrokey as a secure key store for email and (arbitrary) data encryption requires native software. Therefore email encryption in webmail has not been possible with the Nitrokey until now. At the same time strong end-to-end encryption in web applications all share the same challenge: To store users' private keys securely and conveniently. Therefore secure end-to-end encryption usually requires native software as well (e.g. instant messenger app) or – less secure – store the user keys password-encrypted on servers. Nitrokey aims to solve these issues by developing a way to use Nitrokey with web applications.
100% of my premise is that we should not need to always trust the server we connect to. We should be able to secure data on the client, in a way the server cannot access. Because we should not have to trust all data we access to the servers we connect to. It cannot be more basic & simple than that. But this voice & this perspective has been run off the site by confusion & bedlam that obfuscates & distracts from this simple point. I am so sorry.
> No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem.
This is 100% a solved problem already, I have no idea why you are having such a hard time with this.
See PGP/GPG and friends, age[1], magic wormhole[2], etc. Not to mention Noise[0], which I've already mentioned many times, as a protocol that does this. Even MS Exchange supports this for email(S/MIME, OME, etc). Webmail could implement PGP or S/MIME or something similar(and some do last I checked).
> MLS capabilities
Look up Macaroons(for the web) and capability based security. This is also a solved problem.
> 100% of my premise is that we should not need to always trust the server we connect to.
Essentially you are trying to achieve the un-achievable, for various definitions of security and trust, it's just not possible. In the modern web, servers can run arbitrary code on your device AND run arbitrary 3rd party programs on your device, with you having little to no say about it. This isn't limited to the Web, it just makes it ridiculously over the top. Web security is mostly an illusion, it's not going to change anytime soon(arguably never).
Anyways, there is basically zero demand for any of this stuff, and no incentive for companies or organizations to care. We know how to make secure operating systems and software, but nobody bothers.
No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem.
Please, make this pain stop. Why does this thread never go anywhere clear & always goes to misinformation?
I really don't think Nitrokey made everything crystal clear, but it's far far less confusing than where we are right now after this brand new vast massive tragic & sorrowful retrogression in the discussion, so,
> While FIDO is supported by web browsers, using Nitrokey as a secure key store for email and (arbitrary) data encryption requires native software. Therefore email encryption in webmail has not been possible with the Nitrokey until now. At the same time strong end-to-end encryption in web applications all share the same challenge: To store users' private keys securely and conveniently. Therefore secure end-to-end encryption usually requires native software as well (e.g. instant messenger app) or – less secure – store the user keys password-encrypted on servers. Nitrokey aims to solve these issues by developing a way to use Nitrokey with web applications.
100% of my premise is that we should not need to always trust the server we connect to. We should be able to secure data on the client, in a way the server cannot access. Because we should not have to trust all data we access to the servers we connect to. It cannot be more basic & simple than that. But this voice & this perspective has been run off the site by confusion & bedlam that obfuscates & distracts from this simple point. I am so sorry.