Revoke keys

[tobiasKaminsky]

If an user lost the mnemonic he will never be able to use E2E again as there is no restore mechanism neither a way to revoke all keys and start from scratch (with loosing all previously encrypted files).

As #20 I think it should be possible to rekove the keys on server side.

[tacruc]

If you are able to do this on server a evil admin could reset the key, setup a new memonic and on reshare get the secret files or?

I was thinking about using u2f to identify the user who wants to reset his memonic. So clients of users with existing shares to the user could get a the u2f public key and vertify the the memonic reset was requested by the user end not a evil admin?

But I'm not sure if it will work in practice.

[tobiasKaminsky]

Yes, an evil admin could revoke the keys, but then still the can encrypt the files as the keys are stored locally.
An admin cannot setup a new mnemonic as he needs the private key of an user to generate the CSR.

[tacruc]

But if I understand it right than, revoking the key's would not help to resetup end to end encryption. Right?

[tobiasKaminsky]

In current implementation a client only asks for keys (stored on server) on the very first time.
If you then, by accident or on purpose, revoke the keys on the server, you can still access and encrypt the files on the (already configured) client, but cannot add a new one.

[tacruc]

Sorry, I think we are talking about different thinks right now. I was wondering if an admin could use the revoke funktion to "steel" the identity of an user. Ask the other users of shares to reshare (He could setup a message looking as it comes from Nextcloud saying user xyz lost his memomic and reset encryption please reshare, if you want him to be able to read the shares.) and gain access to file he/she should not see on this way.

Or would it not be possible to resetup a new end to end encryption with new key's after the old key's are revoked?

And to protect against this I was woundering if it is possible to use the u2f authentikation to vertify against other devices that the user requested the resetup and not an admin trying to steel the identity of the user.

[tobiasKaminsky]

On very first setup we use tofu (trust on first use), so whoever authenticates with the right credentials can push the keys to the server.
Same will hold for re-setup if you revoke the keys.

But this means that the attacker has access to the user credentials and the user will notice as any new client / file will not be able to decrypt by him.

[tacruc]

So the attacker is the admin, because thats where we need e2e encryption for. Knowing the credentials is not the big problem he is the admin and has write access to the database and all serverfiles.

So the problem or the point where I was woundering is using tofu a second time. I'm not strinktly against it but I think it is a point wich should be well thourgt of, if there is not a bedder solution.

[tobiasKaminsky]

tofu a second time

I guess we have to keep it this way:

• user sets up E2E on device
• user gets the device stolen, breaks it whatever
• user wants to set up E2E again
  --> TOFU at second time

I get your point, but I am unsure how to handle this.
@rullzer @schiessle maybe?

[tacruc]

I see the problem on both ways.
One not relay userfrindly version would be a option to opt-out this for more security.

Or I was thinking of using the users U2F device to autenticate the user, but this is not a easy way for development. The clients must be able to read the U2F device and add the public key to the encrypted shares. The revoke could than happen with a by u2f device singed message and could be done by the server. In this cases each client could vertify that the user and not the server requested the revoke.

Maby a big warning or information on the side of users making a new share that the key has change would solve the problem, too.

[frogueat]

What to do, if the users private key is broken? when i log in i get the message "Falscher privater Schlüssel für die Verschlüsselungs-App. Bitte aktualisieren Sie Ihren privaten Schlüssel in Ihren persönlichen Einstellungen um wieder Zugriff auf die verschlüsselten Dateien zu erhalten."

I am aon 13 beta rc1 and i once tested with the ios app a folder encryption. can't get rid of the message or reset my private key :-( As i am admin on my instance, i tried many things. but there are no keys stored anywhere. Not in occ encryption:show-key-storage-root nor in my data/myuser/... place. Neither in data/appdata_ ... I do have enabled "default encryption module" and "End-to-End Encryption ".

[tobiasKaminsky]

Currently there is no user friendly way.
@schiessle do we plan to implement this?

[jonasgarstick]

I tested E2EE with the beta desktop client when it was first released a few months ago. Back then I did not save the encryption passphrase because I did not plan to use it productively. Now with the new desktop client 2.5.0 and activated E2EE the client asks me now for the passphrase from back then. The possibility of revoking E2EE keys would be very appreciated otherwise I have to create a new user and move all stuff.