Re: Key management for archives

[NdK]

Il 09/06/2017 08:24, Werner Koch ha scritto:

>  ( gpg --status-fd 1 --show-session-key --max-output 1 \
>   -o /dev/null 2>/dev/null FILE || true ) \
>| awk '$1=="[GNUPG:]" && $2=="SESSION_KEY" {print $3}'
> The output can then be used with --override-session-key
Tks! That's exactly what I was looking for.

I'll probably put that in a script that immediately re-encrypts the
session key with the public key of the newly authorized user.
Then he'll decode the session key and use it to decrypt the archive.

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key management for archives

[Werner Koch]

On Tue,  6 Jun 2017 14:39, ndk.cla...@gmail.com said:
> 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?

Here is how I would do that:

 ( gpg --status-fd 1 --show-session-key --max-output 1 \
  -o /dev/null 2>/dev/null FILE || true ) \
   | awk '$1=="[GNUPG:]" && $2=="SESSION_KEY" {print $3}'

Note that gpg exists with a failure (due to the "exceeded --max-output
limit" error message) and for extra cleanness I shortcut that error.

The output can then be used with --override-session-key


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgptLRY1EOcay.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key management for archives

[NdK]

Il 06/06/2017 22:40, Konstantin Gribov ha scritto:

> 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.
There's a big misunderstanding here: the encryption must be automatic,
not done by an user. So, IIUC, the scheme you're suggesting given this
limitation is what GPG already does when encrypting to a recipient's pk:
generate a symmetric key, use it to encrypt the file, encrypt that key
with recipient's pk. And it (hopefully) does every step in the safest
possible way -- surely much safer than anything I could do from a script.
What I'd need is some way to "extract" that temporary key (using the
recipient's secret key, obv) and then immediately reencrypt it with
another recipient's pk. Or (that's equivalent) add another recipient to
the already encrypted file, w/o reencrypting the whole file.

> 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. 
As I said, that's not a problem: once he's had access to a file, that's
"forever" (I cannot avoid he saves the file in plaintext). But he must
not be able to decrypt other files from the archive.

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key management for archives

[Konstantin Gribov]

On Tue, Jun 6, 2017 at 11:03 PM NdK  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
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key management for archives

[NdK]

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.

> Of course, such way doesn't allow you to revoke access to DEK since each
> user could just decrypt his own copy. 
Since encrypting to a public key generates a random session key, the
session key gives access only to that single file. Obviously that access
can not be easily revoked (the user could have saved a plaintext copy
anyway, so that's not a big issue).

> 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.
That's the same of encrypting the DEK with multiple public keys.
The problem is that I don't know in advance the users that will need access.
IIRC there was some method to retrieve the session key and replace the
public key part with another recipient...

> 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).

> 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.
Well, I handle the storage (currently 100TB, going to grow to 150TB
soon). I want to avoid that an attacker could gain access to the whole
archive if he succeeds in compromising the server. Clients are out of my
perimeter (= not my problem).

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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  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@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-- 

Best regards,
Konstantin Gribov
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users