Encrypting a blob with a password

Question

Is there anything to say against to have an amount of public keys, which encrypt a common password for a blob encrypted?

So Users 1,2,3 have all certificates for themselves and can use them to get the master password. With this master password they are able to decrypt the key to the blob and in case they need the contents of it they decrypt the blob too.

The biggest attack vector for common strong encryption algorithms, is afaik most of the time the implementation. If I rely on Framework components for Encryption/Decryption and load the certificate on the fly, assuming the way the certificate (and with it the key) is transmitted, can be considered moderately safe, would you say this is a way to go?

score 3 · Accepted Answer · 2019-08-13T10:24:00.237

The scheme you are describing is called "Hybrid Encryption for Multiple Recipients" and is already well-implemented in GnuPG.

The user David Segonds described it well in this answer on StackOverflow:

GnuPG does multi-key encryption in standard.

The following command will encrypt doc.txt using the public key for Alice and the public key for Bob. Alice can decrypt using her private key. Bob can also decrypt using his private key.
gpg --encrypt --recipient alice@example.com \
    --recipient bob@example.com doc.txt
This feature is detailed in the user guide section entitled "Encrypting and decrypting documents"

The scheme works just as you described it. First, a random Data Encryption Key (DEK) to be used with a symmetric cipher is chosen. Then this key is encrypted, one copy for every recipient, with their respective public key.

Finally, the actual data is encrypted with the DEK. Then the encrypted keys and the encrypted data are stored as a file to be sent to the recipients. For example, the file could look like this:

                  +--- Encrypted DEK
                  |    with the public  +--- This file has been encrypted
                  |    key of Bob       |    by the Data Encryption Key (DEK)
                  v                     v
+---------------+---------------+-----+----------------+----------------------+
| Encrypted DEK | Encrypted DEK | ... | Encrypted File | Signature of Creator |
+---------------+---------------+-----+----------------+----------------------+
  ^                               ^                           ^
  |                               |                           |   (Optional) Signature
  |    Encrypted DEK with the     |    More encrypted DEKs    +--- of the creator
  +--- public key of Alice        +--- of further recipients

Of course, this graphic is purely demonstrative and not actually how the file is structured.

In order for Bob to decrypt the data, he would first validate the signature of the file, if it was signed. Then, he would check all the encrypted DEKs, until he finds the one he can decrypt with his private key.

Once Bob is in possession of the DEK, he can use whatever symmetric cipher was chosen to decrypt the file and receive the plaintext.

@ThoriumBR Nobody has ever been lied to by a hand-aligned ASCII graphic. — , Aug 13 '19 at 10:20
The more recipient the longer the file. Does the signature include Encrypted DEKs? — kelalaka, Aug 13 '19 at 14:14
Yes, the more recipients, the longer the file. It makes sense, since for every recipient, you need to include the DEK encrypted with their public key. As for the signature...good question! I don't know. Both can be done, and both had their own advantages and disadvantages. — , Aug 13 '19 at 15:17

Encrypting a blob with a password

1 Answers1