Changeable password for client side encryption

[jonathann]

Actually passwords used for encrypt files can't be changed.

Why you don't create a big-giant-random-password (P1), encrypt the files with P1, and encrypt the P1 with "user password (P2)"? If the user would like to change the password, he changes password P2; allowing users to change encryption password.

Considering that password P1 is bigger than a normal password choosed by user, the encrypted files are more secure against brute-force attacks.

P.S.: sorry about my bad english

[hbons]

that's a cool idea!

[alpianon]

An even cooler idea would be to implement a simple architecture that enables client-side encryption & usable share features at the same time.

Each project's files are encrypted with a big giant random password (P1). P1 is encrypted with a password chosen by user A, owner of the project (P2A).

If A wants to share the project files with user B, the sparkleshare client decrypts P1 with P2A, re-encrypts with B's public key (sent by B when accepting invitation), and then store it somewhere on GIT server. In turn, B's client downloads the encrypted P1 from the server, decrypts it with B's private key, and then asks B to set her/his own password (P2B) to reencrypt P1.

In this way, each user may have a different encryption password (P2X) while sharing the same encryption key (P1). What do you think?

[hbons]

@alpianon wasn't that what @jonathann was saying? :)

[jonathann]

I think It is the same idea, but applied in another functionality (sharing encrypted folders).

[alpianon]

yesss! It is an implementation of the idea, which however would need that sparkleshare client direclty handles invitations. @hbons do you think that in theory it would be possible?

[rriley]

@alpianon It needs to be made very clear to users that in this case sharing involves the entire repository. I can just imagine the scenario where users think they are sharing one file or folder, but are in fact sharing the entire key. This suggestion also requires the establishment of some sort of public key infrastructure so that you can confirm you have the correct public key for the person you want to share with.

@jonathann Its a good idea. It follows the same pattern that something like Truecrypt or Keepass uses to store the encryption key.

[merlinthered]

You could solve the public key infrastructure problem by using PGP. However if you use such an asymmetric key encryption it would mean there would have to be a separate copy of the repository for each user sharing it (encrypted with their public key). Since the git server can't manage the synchronization between the different encrypted versions this would have to be done client-side too, meaning every time you change something in your sparkleshare folder it has to be encrypted with each user's public key and sent to all the repositories for the different users. In this case it's perhaps better to share the symmetric password with your collaborators (sending it to them encrypted with PGP). You can use a very long symmetric password if you want to.

Changing the (symmetric) password shouldn't be that difficult, right? The client just has to use the new password to encrypt the data and send it to the repository. Everybody else would then have to change the password on their repository too, or they can't access the new commits. Old passwords should be kept so old commits can still be accessed, or they would need to be re-encrypted.

[GitHubGeek]

An idea: How about integrating with an existing file encrpytion scheme, such as EncFS?

[hbons]

though i like the idea, the solution seems quite complex, and i won't have time to work on it since there are other more pressing issues....

so i'm closing, but if anyone does have time to work on it, please do!

[gerhard-tinned]

The idea of alpiano is screaming for a gnupg keyring. ;) you have P1 "the long random password" and this can be encrypted using gnupg. As os such you yould encrypt is with the owners private key plus the public key of every other user that schould be able to open it.

All this is already part of gnupg. Plus, you could even use the private gnupg key to auth via ssh. So no need to have 2 keys (ssh + gnupg)

[gerhard-tinned]

Removing or adding access that way could be done via std. gnupg tools (decrypt and encrypt with the new list of keys).

The list of keys can even be shown to see who has access.

I would love to see that feature. It would secure the password. At the moment it is plain text in a file which is very bad practise.

[hbons]

the password is now stored hashed and salted in master since a few days.

the encrypted hash to encrypt is easy enough to do. the sharing of it with other users is the hard part.