Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I realize SIMILAR questions have been asked before but I'm looking for certain specifics I can't seem to find elsewhere. The following question closely resembles mine but falls short for me on details: Encryption strategies for multi users access in production systems.

I'm creating an application that allows users to add content, which is then encrypted and stored in a database using a content key. This content key is a randomly generated string of 32 characters (since rijndael-256 doesn't seem to support more than 32 characters, or certain utf-8 characters for that matter, but that subject is outside the scope of this question). The content key is also stored in the database, encrypted with the private application key.

What doesn't make sense to me is that next, according to similar posts, each user that should have access to the encrypted content should be given a unique key.

How is this safer than let's say creating a reference for every encrypted row stating which users are allowed to view the encrypted content based on the user's id?

What I'm looking for is a detailed explanation on how to tackle these kind of situations, and furthermore what the keys and passwords (if any) should be derived of.

share|improve this question
1  
You may want to check out Mylar and try to leverage it as your framework: css.csail.mit.edu/mylar –  Eric G May 2 at 23:35

1 Answer 1

up vote 1 down vote accepted

And how does that table grant them access to the files? The entire point of encryption should be that the server can't access the files even if it wanted to. If you just have the data keys stored in a table with a list of who is allowed to access the key, the server can now access the files and encryption is pointless.

Instead, a copy of the content key for the file is encrypted with the public key of the user being granted access and stored in that users keyring (a table much like you described for saying who has access, but storing access keys rather than a simple permission lookup). Without that user logging in and providing their password, their private key can't be decrypted, the content key can't be decrypted and the file can't be accessed using their copy of the content key.

If you want to reject access, you simply remove the content key from their keyring and destroy it (provided that the server has never leaked the content key while they had access, slightly more secure would be to actually change the content key, but that gets costly as it requires re-encrypting the file and all the other keyrings).

share|improve this answer
    
My thought exactly. I'm still trying to figure out how this works in real life though. I create a user, provide him with a public key (random string?) and save it alongside the hashed password. If this is so, than wouldn't the application itself still be able to decrypt the content by first decrypting the content key with the public key saved in the table? I'm still trying to find a detailed real life example (including generation of public/private keys and the encryption itself) for this situation. –  Kevin Op den Kamp May 2 at 14:04
1  
@KevinOpdenKamp - I suggest you read up on asymmetric cryptography. From your comment it sounds like you have some very basic misunderstandings. I was disagreeing with you as I understood what you were saying. Yes, the public key would be stored with the user's record, but it would need to be part of a cryptographically generated keypair. With asymmetric cryptography, the public key can be used to encrypt something such that only the private key can decrypt it. –  AJ Henderson May 2 at 14:19
    
So when a new user is created, you generate a public/private key pair. Store the public key on the user's record, use the user's password with a KDF (key derivation function) to produce an encryption key, use that key to encrypt the private key and store that on the user's record as well. From there, the public key can be used to encrypt any content keys that the user needs to have access to and the system can use the user's password on login to load their private key in to the session, thus making it so their keyring can be opened. –  AJ Henderson May 2 at 14:20
    
I'll do some more reading then. From what I read so far it seemed that symmetric encryption was the way to go but I'm starting to think that is impossible on a multi user encryption platform. Thanks –  Kevin Op den Kamp May 2 at 14:20
    
@KevinOpdenKamp - For a multi-user system, you need asymmetric cryptography unless both users are involved in encrypting the file. You use symmetric cryptography for encrypting data, you use asymmetric for exchanging keys with another user. In theory, if both users were online, you could have one user give the data key to the other and have them then encrypt it so only they can access it, but there is no secure way to save a content encryption key for another user with symmetric cryptography if the system doesn't have access to that user's key, which defeats the whole point of encryption. –  AJ Henderson May 2 at 14:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.