Key management for archives

[Konstantin Gribov]

Diego,

I can think of more simpler approach:
- generate secure random for symmetrical data encryption key (DEK);
- encrypt that key for authorized users on their public keys;
- encrypt data itself with something like ChaCha20 or AES in appropriate
mode.

In such case you could give end user an archive, info about cipher and its
mode and a data encryption key.

Of course, such way doesn't allow you to revoke access to DEK since each
user could just decrypt his own copy.

A bit more complicated approach is to use two level system:
- generate data encryption key (DEK);
- generate key encryption key (KEK) for each authorized user;
- encrypt each user's KEK on each user's public key;
- create a table (tsv/csv or any other format) with some user id and DEK
encrypted with corresponding KEK and store it with data;
- encrypt data with DEK.

Then to decrypt archive authorized user decrypts his KEK, use it to decrypt
DEK and gives end user archive, DEK and cipher info.
To revoke a key you just remove entry from table with KEKs.

Both methods are naive and gives end user DEK, so it's better to reencrypt
archive after that to rotate DEK.

In both approaches authorized user can get encrypted archive, retrieve DEK
and reecrypt archive with stream or block cipher with very small overhead
(block size at minimum).

Also, a lot depends on your threat model. Since I don't know what risks are
you planning to avoid with original scheme I just assumed that primary risk
is 3rdparty archive storage compromise.


On Tue, Jun 6, 2017 at 4:39 PM NdK <ndk.clanbo at gmail.com> wrote:

> Hello all.
>
> I'd need to handle an archive with many big files (~200GB each). The
> system receives "plain" files in a "dropbox" folder, then encrypts 'em
> to a (set of) public key(s) (no corresponding private keys on this
> system) and deletes source files.
> Up to this point it should be OK (a cronnable script with a lot of
> checks is mostly ready).
>
> But my big doubt is how to handle archive reading in an efficient way.
> The naive way would be to let an authorized user decode the file and
> reencode it for the requester, but that would mean that this authorized
> user should have quite a lot of space available (twice the dataset size,
> at least).
> Is it possible to "extract" the used session key, so that the requester
> just ignores the asymmetric crypto and just uses the symmetric key to
> decode the file? Drawbacks? Other ideas?
>
> Tks,
>  Diego
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-- 

Best regards,
Konstantin Gribov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170606/6889f60e/attachment.html>