3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ So you want anyone of your 20 users to be able to decrypt the document? There's nothing "fancy" involved such as any 2 of the 20 should be able to decrypt? In the former case prepending the document's key encrypted using the users' keys is the standard solution. $\endgroup$ – SEJPM Nov 27 '15 at 19:10
  • $\begingroup$ @SEJPM That's correct, any single one of 20 users can decrypt it. In contrast to shared secret encryption where any 2 out of 20 users have to combine their keys. $\endgroup$ – patmanpato Nov 28 '15 at 4:36
2
$\begingroup$

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)
$\endgroup$
  • 1
    $\begingroup$ I've chosen TEA as the last resort here because it was designed to be simple and is still secure if no related keys are involved (like here). If EAX / CCM allow for attacks please go ahead and suggest an alternative to TEA. $\endgroup$ – SEJPM Nov 28 '15 at 13:55
  • $\begingroup$ Thanks! That's a lot to digest! I'm glad to know I was roughly on the right track. Thank you for all the extra important details though. I would upvote (many times) if I had the reputation to allow it. $\endgroup$ – patmanpato Nov 28 '15 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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