Encryption - are multiple keys possible ?

[david_navigator 12]

Hi

I don't really know much about encryption and have been tasked with designing a system where the customer has the following requirements and I've no idea if it's possible and if it is possible, what terms I should be using to search Google for more info.
Simplifying as much as possible, basically the customer wants to store his driving license info and his passport info in an encrypted file.
He then wants to be able to give Tom, Dick and Harry, a key each, such that Tom can only decrypt the driving license, Dick can only decrypt the passport but Harry's key can decrypt either.
Is this possible (In reality there are 1000's of documents and 100's of keys required) ?

 

(My guess is that I probably need to encrypt each document with different keys and then encrypt the appropriate set of public keys for each of Tom, Dick & Harry ?)

 

Many thanks

 

David

 

 

[Lars Fosdal 1730]

Looks like you are describing a mix of public key encryption (PKE) and access control. 
PKE only has one encryption key and a one decryption key.

Would it not be easier if Harry simply has both keys - one for the driving license and one for the passport?

 

That would mean - one document, one encryption key, and one decryption key, with a list of people that has access to the decryption key for each document.

 

Or - you could turn that around - one encryption key, one decryption key for each document owner and a list of people who has access to which documents (the documents share the same decryption key).

[Guest]

Well, there is method(s) and algorithms to do that exactly but, with huge BUT here.

 

Modified Shamir secret sharing (SSS) can do that, and even the better one Homomorphic secret sharing (HSS), their problem is performance, the more keys the slower in an exponential way, also adding one key in the future will require re-encrypting the data in whole to support the new key.

 

To my knowledge there is no implementation for HSS in Pascal, but StreamSec has SSS in SS Tools v4, i have PKC4.0 and StreamSec 2.3 and they really lacking documentation, so i don't know about SSv4.

In all cases Secret Sharing algorithm in your case should be modified to allow one key to decrypt, while keep passing over the keys for each document, this is not easy thing to implement.

 

Lars suggested PKE, first lets correct a thing here, PKE meaning Public Key Exchange not encryption, Elliptic curves cryptography can do PKE but can't encrypt/decrypt ( the term is used loosely for key exchange for simplicity ), while RSA and ElGamal can do both PKE and encryption/decryption.

 

Anyway, i doubt handling homographic encryption will be your cup of tea, while adding PKI (Public Key Infrastructure) will not make things easier or shorter (smaller keys), so as you assumed the easier way is to encrypt each document with its own asymmetric key, this will keep things fast and small,

after that either send these keys protected in a container locked with a password to each user accordingly or even better, supply each user with a password (may be a key or even credential), and let them only do the encryption online, meaning you need to write a server to authenticate each one then either send him the decryption key or decrypt the document for him online then send it back, the main benefit of having such centralized server is you know who is accessing the data and when, this might be nice feature to have or bad thing to do, i think you got the idea.

By container, i meant what you already mentioned it could be protected with ECIES, PKCS#5, ...

 

Just food for thoughts.

[ioan 44]

Are you going to keep the documents in a database or a file each?

If you are keeping them in a database, you can give access based on a login/password (call it "encryption key") to anyone you want in any way you want, any combination.

Why not do that?

[david_navigator 12]

14 hours ago, ioan said:

Are you going to keep the documents in a database or a file each?

If you are keeping them in a database, you can give access based on a login/password (call it "encryption key") to anyone you want in any way you want, any combination.

Why not do that?

They will be in a database but the database I'm using doesn't offer record level access rights (do any ?)
It is important that the actual data is encrypted as it must be impossible for the stolen table to be easily read, moreover if the database was stolen by Tom he shouldn't be able to decrypt Dick & Harry's data.

Edited September 1, 2021 by david_navigator

[david_navigator 12]

19 hours ago, Kas Ob. said:

so as you assumed the easier way is to encrypt each document with its own asymmetric key, this will keep things fast and small,

after that either send these keys protected in a container locked with a password to each user accordingly or even better, supply each user with a password (may be a key or even credential), and let them only do the encryption online, meaning you need to write a server to authenticate each one then either send him the decryption key or decrypt the document for him online then send it back, the main benefit of having such centralized server is you know who is accessing the data and when, this might be nice feature to have or bad thing to do, i think you got the idea.

By container, i meant what you already mentioned it could be protected with ECIES, PKCS#5, ...

 

Just food for thoughts.

Thanks. The above sounds the way ahead. Homographic encryption certainly doesn't sound my thing !!!

[Guest]

21 hours ago, ioan said:

Are you going to keep the documents in a database or a file each?

If you are keeping them in a database, you can give access based on a login/password (call it "encryption key") to anyone you want in any way you want, any combination.

Why not do that?

Yes, this is what i usually suggest to my clients in this situation.

"So we have "our" system, your needs do NOT extend outside the users of this specific system.

Sooo.... instead of trying to adopt complex standards, let's code that auth/access/sign processes."

But of course, it's about reach and scope. Specific to any implementation.

[Guest]

6 hours ago, david_navigator said:

They will be in a database but the database I'm using doesn't offer record level access rights (do any ?)
It is important that the actual data is encrypted as it must be impossible for the stolen table to be easily read, moreover if the database was stolen by Tom he shouldn't be able to decrypt Dick & Harry's data.

Sound a bit... confused to me. Could you clarify?

 

6 hours ago, david_navigator said:

They will be in a database but the database I'm using doesn't offer record level access rights (do any ?)

Oh, yes! But i am not sure that is what you need.

The RDBMS access setup should be one "metalayer" down.

I hope you do not enter all those 1000 users into a "GRANT X FOR Y ON Y" repeating... like 100K times?

Use roles or groups or even much muc better a middle-layer and manage you users in a table (not a system-table).

[Guest]

6 hours ago, david_navigator said:

Homographic encryption certainly doesn't sound my thing !!!

Then you are not alone!

[david_navigator 12]

2 hours ago, Dany Marmur said:

Sound a bit... confused to me. Could you clarify?

I don't want anyone other than Tom, Dick & Harry to be able to access the data.
So a DBA shouldn't be able to run a query and see the unencrypted data, however I've just noticed a more fundamental flaw in what the customer is proposing, so I need to address that first.

[Guest]

54 minutes ago, david_navigator said:

So a DBA shouldn't be able to run a query and see the unencrypted data

That is surely doable but i would say it can easily become very costly and convoluted.

I would probably opt to cordon off stuff in other "dimensions".