Key management for archives

[Konstantin Gribov]

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

> Il 06/06/2017 20:13, Konstantin Gribov ha scritto:
>
> > 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.
> Problem: the symmetric key (DEK) must remain in plaintext on the server.
> It's a relatively secure setup, but I prefer *not* to risk. Even if that
> means a slightly more involved process. If the server gets compromised,
> the attacker can only access new datasets, at most, not the historic
> archive.
> Moreover, with your proposal, once I give an user access to one file,
> he'll be able to decrypt *any* other file too.
> If I keep track of who can access every dataset and some day I find some
> datasets are being used "illegally", I can restrict the suspects.

Sorry, I was misunderstood. I'll try to rephrase.

In first scheme DEK is never stored in plain text. It used while encrypting
archive and encrypted with gpg (or any other cryptographic means) and plain
text version is removed right after that.

Also, in this setup unique DEK is generated for each archive, so DEK for
one archive doesn't give user an access to any other archives.

> Both methods are naive and gives end user DEK, so it's better to
> > reencrypt archive after that to rotate DEK.
> That would be a big problem: archives must remain static (to avoid
> troubles with offsite replication).
>
Then you can reecrypt archive on one of the servers with new DEK dedicated
for that user. Or just let it be so. If user gained an access to archive he
could always decrypt same archive again.

Anyway with unique DEK for each archive giving user this key doesn't seems
to be an issue to me. Just reread my original answer with this assumption,
it could put a new face on it.

-- 

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