-1

Possible Duplicate:
Encryption strategies for multi users access in production systems

I would like to develop a service on wich clients would connect and retrieve informations. These informations could also be shared with others.

It's very simple but, I would like to encrypt the data as only the client would have access to all his informations and the others to only what the client have granted.

In a scheme :

+----------------+              +----------------+
|  SHARED DATA   |              |Client 1 Shared |
|                | ============ | Data           |
|----------------|              |----------------|
|  UNSHARED DATA |              |  UNSHARED DATA |
+----------------+              +----------------+
       ||                               ||
       ||                               ||
       ||                               ||
       ||                               ||
       ||                               ||
    +--------+                      +--------+
    | Client1|                      | Client2|
    +--------+                      +--------+

I was thinking of asymetrical encryption, but as I'm not familiar with that, I wanted to know, how could I store keys for that (the client is an eyeball, he have only a password, he can't be uploading/retrieving keys).

Multiples problems/questions coming : If I encrypt the keys with his password. He loses all his informations...

Should I use a private key to encrypt the data wich will be shared, (if someone get a public key, he would be able to access, maybe a handshake or something could counter that) ? Or a public key given by the second service ? In that case, the service n°1 have to be able to read the data to encrypt it...

If I encrypt the data any time something has to be shared, I will lose efficiency, don't I ?

I really don't know how to proceed. My goal is to protect most of the user-data. What do you suggest ?

Thanks in advance.

MisterDoy
  • 1
  • 1
  • I'm confused. The diagram shows two instances of Client1. Do you want to act as an information sharing broker? Allowing Client1 to share data with Client2 and Client2 to share data with Client1. However, this can be done with existing PKI with no intermediary. Are you generating data for the clients? – this.josh Jun 27 '11 at 06:33
  • 1
    I don't understand the question. @MisterDoy, I suggest reading the FAQ, then explaining more clearly what problem you are trying to solve, what security threats you are trying to prevent, what the threat model and requirements are, etc. – D.W. Jun 27 '11 at 07:04
  • Hi @MisterDoy, welcome to the site! Please read the [FAQ] and [ask]. Also please use the search function, since many common questions have already been asked, and answered well. – AviD Jun 27 '11 at 08:17

1 Answers1

1

"Should I use a private key to encrypt the data wich will be shared"

No, the PUBLIC key is used to encrypt data, the PRIVATE key is used to decrypt it. The key available to everyone does not decrypt the data. So if I have something encrypted that I want to share with you, I decrypt it using my private key, then re-encrypt it using your public key and 'send' the encrypted information to you. If you are using some form of shared database, then the 'send' is more a process of informing you that it is available to you.

Obviously the original and shared copy are different sets of bytes (one is encrypted with my keys, the other with yours) so you have twice as much storage.

Also because the transmitted data is encrypted any malware in the content can't be readily detected.

Whether the end customer is the only one holding the private key or whether you hold a copy is dependent on your target users. Having you hold a copy poses additional risks for confidentiality but reduces the risks of the customer losing the key. That might work as a business model if customers believe you can be trusted. It wouldn't be something I'd use for confidential information though.

Gary
  • 884
  • 7
  • 12
  • 2
    No need to store two copies of the data. Just have a symmetric decryption key unique to it, and store copies of that key encrypted with the asymmetric keys. – nealmcb Jun 27 '11 at 05:37