Share KeeShare files using asymmetric encryption

[zarmhast]

Summary

When using KeeShare it is possible to cryptographically sign exported sets, in order to confirm that it was generated by a trusted party. It would be nice to be able to encrypt the whole thing using the target's public key, so that only 1 person could decrypt it, verify that it was generated by a trusted party, import changes.

Examples

• Alice and Bob know each other's public keys.
• Alice encrypts the KeeShare export with Bob's public key
• Only Bob can read that KeeShare file without the need to share a symmetric key like a password.

Context

Need to share some data from my database with a different person, but had no trusted channels of communication to transfer both the .share file and its password.

[droidmonkey]

If you have the targets public key why not just send them an encrypted email?

We won't be implementing this feature for keeshare.

[zarmhast]

Good question. You do have a point there, but from a UX perspective that would involve additional steps, tools, not to mention the fact that either of those people, or both can be not tech savvy enough to know how to use all those tools.

I've had this idea, and just thought I'd share it. If no one is going to implement it - then, please just close this issue.

Thank you for your attention.

[droidmonkey]

I will consider it, but it would only be in the context of "Export Share to Encrypted Container" and you can choose the targets public key to encrypt the zip file itself and embed the password into the zip file. When the target "Imports encrypted container" then it reverses the process and stores the password in the user's database instead of the zip file.

[zarmhast]

To me that sounds like a good idea.

[kzar79]

We were discussing a similar problem yesterday with a friend, and we depicted a possible solution that involves asymmetric encryption.

The problem is similar to #4091, i.e. being able to share distinct groups of passwords with distinct bunches of people without telling them the same password(s), and with the possibility to add and remove people that have access to the group(s).

The problems of symmetric encryption are notorious: you must share the same password over a secure channel with all the people, who can then tell the password to someone else, which forces you to change the password and share it again with everybody. Plus, if you have access to a lot of different groups of password, you must manage a lot of different passwords.

All of that is solved by asymmetric encryption. You need just to select the people (of which you already have the public key) with which you want to share a group. A random password is then generated to symmetrically encrypt the export, and that random password is encrypted with each public key, so all the recipients can decrypt it with their private key. If you want to add somebody, you just need to encrypt the random key again with their public key. If you want to remove somebody, you just need to generate a new random password and encrypt it only with the public key of the remaining people.

Gpg and Pgp do this since ages, and with my friend we were discussing creating a script to encrypt/decrypt the exported kdbx.share with the public keys of the recipients.

But given that KeeShare already has some public/private key management (currently only used for signing), it could be extended to be used also for encryption.

The process would be quite simple: all the users generate their keys (which are standard ssh-rsa) inside KeePass, which is already possible. Then they export only their public keys to the folder where they will also share the exported kdbx.share(s). When the first user creates a share, he chooses the path of the KeeShare export, the program loads the list of the public keys it finds in the folder. The user can decide to type a single password, or to choose the people with which he wants to share the export.

When a user imports a share, the program just checks if the random password can be decrypted with the private key. When the users re-export the share, the program just re-encrypts the share with the same random password (except when the list of public keys changes).

There are more complex things than could be done using this model, but they would be useful only to very few people, so I do not recommend to implement them. Anyway, it could be possible, for the original creator, to decide which users can change the list of allowed public keys (simple: the list must be signed by one of the "owners"). It could be even possible to create read-only users and read-write users (the export must be signed by one of the read-write users, the list of which is signed by one of the owners).

Now unfortunately I am not very good at C++, but I would be happy to help in any way to implement this useful feature, for example with a more detailed analysis of the algorythms and file formats.

[droidmonkey]

We are actually removing all the signing aspects of keeshare in the next major release. The use of asymmetric encryption using user held keys is extremely niche. We won't be introducing anything more complicated then what I proposed above. KeePass databases are not meant to be sharing vehicles, you are looking at a totally different application that is purpose built around that model instead.

[The00Dustin]

I guess I'm niche, because I think the proposal here and the proposal referenced here could work well even if they need a "password sharing is bad" disclaimer. It seems to me like an export file could be assigned for each public key assigned to each group (or password if you really wanted to get granular), and then the automatic keeshare functionality would be automatic asymmetric sharing functionality. I could see this being very beneficial to me over the basic keeshare functionality, which I only just found out about and was planning to implement.

Considering the planning to implement part of my scenario, what does "removing all the signing aspects of keeshare in the next major release" look like? I can't seem to get keeshare export working without creating a personal certificate, which I would (perhaps incorrectly) assume means I can't currently use keeshare without signing. Will the next major upgrade require completely reconfiguring keeshare for all exporters and importers?

[droidmonkey]

When setting up your shares don't choose the .share.kdbx option, just use .kdbx