> - secret sharing (Algorithm: Shamir, ...) > > read:http://en.wikipedia.org/wiki/Secret_sharing,http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
Secret sharing schemes are methods of splitting a key amongst many persons, such that one needs all of the partial keys to be able to decrypt the data in question. This is not what David and Titang are inquiring about. (Also, in my previous post I misused the term 'salt', which is usually reserved as an entropic addition to make a one-way hashing algorithm more secure. I should have said 'key for symmetric encryption algorithm'). David, Titang, there exist such encryption schemes which would fill your necessary requirements of complete data encryption and modularized access to portions of the data using independent keys. I'll try to be as clear as possible, but the scheme that you need is slightly more complex than what I have previously described. If you're not too familiar with public key encryption, especially the difference between a public and a private key, please read up on it. I'm sure the wikipedia article can provide the necessary details. 1) The data is created by the initial user, which we will call the 'parent'. The data is encrypted on the database using standard public key encryption. Store the public key along with the data (or in another table if you want to normalize). Store the private key & associate it with the user who created it. Encrypt this private key using a symmetric encryption, using a passphrase provided by the user. When the user wishes to view the data, you ask for the passphrase, use it to decrypt the private key, and use the private key to decrypt the data. As a result, the user is never aware of the contents of the private key, and even if you have access to the raw data in the database you are unable to view the data, because the private key is encrypted. 2) To allow others to view the encrypted data, the 'parent' will need to be involved; this is expected, since you need some authoritative method of determining who should get access to the data that was created. The parent creates a new user (called a 'child'), and the parent uses his passphrase to unencrypt the private key and copy it over to the child account. The copied private key is then encrypted with a passphrase (randomly generated), and this passphrase is sent to the new user (you can allow the new user may then change the random passphrase to his/her liking simply by providing a 'change password' form, whereby you ask for the provided random passphrase and a new passphrase. Use the former to decrypt the private key, and encrypt it with the new passphrase). Now when a child account requests to access the encrypted data, you use their passphrase to decrypt the private key, and use the decrypted private key to view the data. 3) Each time a new user needs access to the data, the 'parent' would perform the same actions as described above. In this manner, all the 'child' users and the 'parent' have access to the data using their own passphrases, and the actual data in the database is protected from anyone, even if you have root access, since you need the private key to decrypt the data, and all private keys of the users are encrypted with a symmetric algorithm which requires a passphrase. 4) When you need to add new data or modify existing data, it can be encrypted by anyone using the public key, which was stored somewhere on the database & associated to that data. As a result, any of the users who can view the decrypted data may add/edit data, and the result will then be encrypted with the public key. The data is then only viewable to users who have a copy of that private key, which is a feature of the scheme described above. Limitations: - New users need to be created by pre-existing users who already have access to the data. You can limit this to the 'parent' by providing an appropriate flag. - Since a private key is associated to the public key that is used to encrypt the relevant data, for each 'data group' that a user has access to, you will need to store an encrypted private key. E.g. if User1 has access to data1, and User2 has access to data1 and data2, and User3 has access to data2, then User2 will have two encrypted private keys, one for each data group he is able to view. Sorry for the length of the post. If google groups allowed LaTex typesetting and Venn diagrams, I could have been much more brief ;-). -J. On Oct 8, 1:38 am, "Bernhard J. M. Grün" <[EMAIL PROTECTED]> wrote: > Hi! > > Here are some of my ideas for that problem: > - public key encryption (Algorithms: RSA, ElGamal, ...) > read:http://en.wikipedia.org/wiki/Public-key_cryptography > You should combine those algorithms with traditional cryptography (i.e. > AES) - called hybrid cryptography > - secret sharing (Algorithm: Shamir, ...) > > read:http://en.wikipedia.org/wiki/Secret_sharing,http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing > > Idea: > Just save your data more than once for every user but with its own (public) > key. > > This mail is short because I am short in time at the moment. Anyway I hope > this helps. > > -- Bernhard J. M. Grün > > 2008/10/8 David C. Zentgraf <[EMAIL PROTECTED]> > > > > > I'm very interested in this topic. > > > I have an application that by it's nature shares "objects" between > > multiple participants, each object having different participants. > > Since those objects contain sensitive data, I was looking into ways to > > encrypt those, so that not even the database admin could see the > > content. > > > With "traditional" encryption schemes this is very difficult to > > realize though, as there's always only one key that can decrypt the > > data (would be pointless otherwise). That means for every object a > > user is participating in you'd need to store an additional key with > > the user's data, which is pointless. > > > I haven't yet, in my limited research, found a meaningful way to > > encrypt data in a way that allows it to be decrypted with any one of > > multiple keys (i.e. the user's password). But I'm no cryptographer by > > any means. Are public/private keys a way to do this? > > > Chrs, > > Dav > > > On 8 Oct 2008, at 12:37, titang wrote: > > > > It sounds good, but what about if the data must be accessible by many > > > users. > > > For example I want to let 2 users to access the same datas with their > > > own passphrase... > > > > Is there a simple way to do that ? > > > > Titang > > > > On Oct 8, 11:03 am, Joel Perras <[EMAIL PROTECTED]> wrote: > > >> Simple solution: Generate a pseudo-random string of characters (or > > >> let > > >> him choose his own passphrase), and use this as a salt to encrypt > > >> your > > >> data before saving to your database. The passphrase must then be used > > >> to retrieve any information from the database. > > > >> Of course, all of this is completely useless if you don't use SSL for > > >> the entire request/response process. > > > >> -J. > > > >> On Oct 7, 3:50 am, titang <[EMAIL PROTECTED]> wrote: > > > >>> Hi, > > >>> I would like to encrypt/decrypt data in my application regarding the > > >>> following requirements: > > >>> - The data will be decrypted by many users. > > >>> - I dont want to keep the secret password for decrypting the data of > > >>> each users in my application. > > > >>> Does someone have any idea about how can I do this ? And if there is > > >>> something already implemented for the cakephp framework? > > > >>> There is something pretty good, it is the gnupg project. > >http://www.gnupg.org/ > > >>> I did my first test by command line on Linux, and it seems really > > >>> good. > > >>> 1. First i have to generate one public key per users (from an uid > > >>> and > > >>> a passphrase). > > >>> 2. Then i encrypt the data and specify which users can access the > > >>> data (by specifying the uid). > > >>> 3. And the authorized users can decrypt the data with their own > > >>> passphrase > > > >>> An extension gnupg is available for php. > > >>> What about a cakephp behavior using this extension? I think it could > > >>> be very useful. > > > >>> Any suggestions or helps are welcome ! > > > >>> Thanks --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
