Re: Key management for archives
On Tue, Jun 6, 2017 at 11:03 PM NdK <ndk.cla...@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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key management for archives
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.cla...@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@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
Re: Don't send encrypted messages to random users
Yes, they could. But publishing all subkeys is simpler than publishing some of them. And key is usually generated with both sign and encryption subkey as many guides, howtos etc guide people to. To look at such test emails from the other point of view just imagine that someone found your email on public repo/bugtracker/ml starts to spam you with test emails. Such an event certainly would upset me. Another thing which shocked me is statistics from Golang folks [1]. Brad Fitzpatrick said: > 99% of the PGP-encrypted emails we get to secur...@golang.org are bogus security reports. Whereas "cleartext" security reports are only about 5-10% bogus. Getting a PGP-encrypted email to secur...@golang.org has basically become a reliable signal that the report is going to be bogus, so I stopped caring about spending the 5 minutes decrypting the damn thing (logging in to the key server to get the key, remembering how to use gpg). > ... > In summary, the PGP tooling sucks (especially in gmail, but really everywhere) and it's too often used by people who are more interested in using PGP than reporting valid security issues. When he says "cleartext" it's plain text send over TLS MTA-to-MTA connections. Almost all mail providers use starttls now. [1]: https://news.ycombinator.com/item?id=14123388 вт, 30 мая 2017, 8:46 Ineiev <ine...@gnu.org>: > On Mon, May 29, 2017 at 11:52:27PM +, Konstantin Gribov wrote: > > > > As an example, many open source devs are publishing their keys which they > > use for signing software releases but rarely for encrypted communication. > > On the other hand, they could publish certificates without encrypting > subkeys. > -- Best regards, Konstantin Gribov ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Don't send encrypted messages to random users
Primary reason to publish a key is to make it available for fetching. It isn't a permission for anyone to annoy a person anyhow. As an example, many open source devs are publishing their keys which they use for signing software releases but rarely for encrypted communication. On Tue, May 30, 2017 at 2:28 AM listo factor via Gnupg-users < gnupg-users@gnupg.org> wrote: > This I find surprising: if one does not want receiving > encrypted messages from those that he does not have > existing relationship with, why does he publish his > public key on public keyservers? > > ___ > 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
SSH RSA comment lost when imported to gpg-agent
Hi, folks. I've found strange `gpg-agent` behavior. When I import `~/.ssh/id_ed25519` with `ssh-add` it takes comment from its public counterpart. But when I do the same with `id_rsa` it just use `.ssh/id_rsa` instead of actual comment. Is there any way to change that comment via `gpg-connect-agent`? Env: Arch Linux, GnuPG 2.1.20. -- Best regards, Konstantin Gribov ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
