Multi-Party Encryption for a Shared Document

Question

Is there an encryption algorithm/protocol where any of a pre-defined set of keys/passwords will succeed in decrypting a document? The number of keys can be fixed, say, 10 or 20 possible passwords.

The context is a single application (with a single embedded document), with no server-side component. It should be shareable amongst users, where any password, within a pre-defined set of passwords, will succeed in gaining access (decrypting the document).

EDIT: In thinking about this, can I append a (symmetrically) encrypted key to the document, where the password to decrypt this is a user's password? I.e. for each user, append the master-key after encrypting it with the users password. I'm not sure what algorithm is appropriate here, or whether this is at all secure.

Disclaimer: I'm fairly new to cryptography beyond the basic concepts and implementations - I don't know the terminology very well, and therefore I was unable to find a similar question posted.

Answer 1

Is there an encryption algorithm/protocol where any of a pre-defined set of keys/passwords will succeed in decrypting a document?

Not exactly a protocol, but there are formats out there that will allow this sort of thing. An example system using a similar appraoch would be LUKS which offers "key-slots" doing exactly what you want - but targeted at full disk encryption.

[C]an I append a (symmetrically) encrypted key to the document, where the password to decrypt this is a user's password?

Yes you can, although usually these information are put in front of the document so you don't have to start at the end to gather the key and then jump to the front again.

I'm not sure what algorithm is appropriate here.

I'm quickly describing what each key slots needs to hold. The extrapolation to 20 slots is then trivial.

• The slots may hold an identifier so each user can quickly discover his slots. This may be a hash (SHA-3-256 or SHA-256) of the the email, or other appropriate identifiers.
• The slots may hold algorithm identifiers for key derivation, for encryption and for authentication in case you plan on changing the format in the future.
• The slots should hold a unique, random 16 - 32 byte salt each.
• The slots should hold derivation parameters for the key derivation.
• The slots must hold a unique, random IV of length 12 - 16 bytes each.
• The slots must hold the encrypted document key and the encrypted IV for the document.

As for the algorithms:

• The key derivation algorithms (in order of preference):
  1. Argon2, the winner of the password hashing competition (PHC), will need at least two parameters and a salt along with the password, you may lack an implementation of Argon2 because it is fairly new
  2. any other PHC recommendation (except Makwa), they are all fairly new and you may you not have an implementation, they all will need a salt and at least two parameters
  3. scrypt, will need three parameters and a salt and is more likely to be available than Argon2 and the PHC recommendations and uses large amounts of memory
  4. bcrypt, will need only one parameter and a salt and is likely to be available
  5. PBKDF2-SHA256, is 100% available or you can quite easily implement it yourself
• Encryption algorithms for the document key, the document IV and the document (in order of preference):
  1. AES-GCM / AES-OCB, use AES-OCB if available but chances are you can't because of the patent, if available AES-GCM is your best option then
  2. AES-CCM / AES-EAX, use these modes if possible or if necessary implement them yourself if you have access to an AES primitive.
  3. AES-CTR + HMAC-SHA-256, use this mode in an encrypt-then-authenticate manner and only use it if you have AES and HMAC at your disposal but can implement EAX or CCM.
  4. 3DES-EAX / 3DES-CCM, use this if you have access to an implementation of 3DES (or just DES) and implement EAX / CCM on top.
  5. TEA-EAX / TEA-CCM, use this if you don't have access to any implementation of any block cipher (highly unlikely)