Re: [pacman-dev] GPG remote signing
On Fri, Jun 10, 2011 at 5:45 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I've done a fair amount of research on what we might be able to do with this during the afternoon here. Some observations below. This is mainly addressing point four in Thomas' prior email (http://mailman.archlinux.org/mailman/private/arch-dev/2011-May/014193.html). Could you please explain what the situation is? I do not have access to the arch-dev archives. In particular, what do you mean by "location A" and "location B"?
You want developers to be able to sign databases without copying them to their local machines, correct? I vote for (4), then. (1) provides complete security against an attacker with access to the main server, but it may be hassling. (2), (3), and (4) ultimately don't provide any security against an attacker with access to the main server (at least until the attack is discovered), but with (2) and (3) keys will need to be revoked after an attack (the developer's and the server's, respectively), whereas with (4) nothing will have to be done (except secure the server). Also, an attack against (4) would probably be harder to mount for the attacker and easier to notice for the developers. It seems there will be a locking issue as Denis mentions, but I don't fully understand the problem, so I can't say. -Kerrick Staley By the way, an (overdue) disclaimer: I'm just an idiot with no formal background in cryptographic systems, so I don't necessarily know what I'm talking about.
On 2011/6/12 Kerrick Staley <mail@kerrickstaley.com> wrote:
On Fri, Jun 10, 2011 at 5:45 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I've done a fair amount of research on what we might be able to do with this during the afternoon here. Some observations below. This is mainly addressing point four in Thomas' prior email (http://mailman.archlinux.org/mailman/private/arch-dev/2011-May/014193.html). Could you please explain what the situation is? I do not have access to the arch-dev archives. In particular, what do you mean by "location A" and "location B"?
You want developers to be able to sign databases without copying them to their local machines, correct? I vote for (4), then. (1) provides complete security against an attacker with access to the main server, but it may be hassling. (2), (3), and (4) ultimately don't provide any security against an attacker with access to the main server (at least until the attack is discovered), but with (2) and (3) keys will need to be revoked after an attack (the developer's and the server's, respectively), whereas with (4) nothing will have to be done (except secure the server). Also, an attack against (4) would probably be harder to mount for the attacker and easier to notice for the developers.
I personally vote for signing the hash, but not for having two sorts of signatures. Isn't there any way to split GnuPG's code into the hashing part and the encryption part? Rémy.
On Sun, Jun 12, 2011 at 4:19 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
I personally vote for signing the hash, but not for having two sorts of signatures. Isn't there any way to split GnuPG's code into the hashing part and the encryption part?
Rémy.
From the gnupg-users@gnupg.org mailing list:
On Mon, Jun 13, 2011 at 3:47 AM, Werner Koch <wk@gnupg.org> wrote:
On Sun, 12 Jun 2011 23:15, mail@kerrickstaley.com said:
Is it possible to generate the digest for a file, and then create the signature from that digest later?
No, this is not possible. We once considered to implement such a feature but dropped that plan. The technical problem is that with OpenPGP you don't just sign a plain hash of the message but the hash of a modified message (in text mode) and further the hash includes a few magic bytes. Thus to implement such a feature we we would need to do a incomplete hash on the server and complete it on the client. It is doable but would look ugly.
My suggestion is to sign a the hash of the file; i.e. create a file with the SHA-x digests on the remote box, download it and sign it on the local box.
So, no (unless we create our own implementation, but that'd be more complicated than just accepting signed hashes). -Kerrick Staley
On Mon, Jun 13, 2011 at 9:35 AM, Kerrick Staley <mail@kerrickstaley.com> wrote:
On Sun, Jun 12, 2011 at 4:19 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
I personally vote for signing the hash, but not for having two sorts of signatures. Isn't there any way to split GnuPG's code into the hashing part and the encryption part?
Rémy.
From the gnupg-users@gnupg.org mailing list:
On Mon, Jun 13, 2011 at 3:47 AM, Werner Koch <wk@gnupg.org> wrote:
On Sun, 12 Jun 2011 23:15, mail@kerrickstaley.com said:
Is it possible to generate the digest for a file, and then create the signature from that digest later?
No, this is not possible. We once considered to implement such a feature but dropped that plan. The technical problem is that with OpenPGP you don't just sign a plain hash of the message but the hash of a modified message (in text mode) and further the hash includes a few magic bytes. Thus to implement such a feature we we would need to do a incomplete hash on the server and complete it on the client. It is doable but would look ugly.
My suggestion is to sign a the hash of the file; i.e. create a file with the SHA-x digests on the remote box, download it and sign it on the local box.
So, no (unless we create our own implementation, but that'd be more complicated than just accepting signed hashes).
Not to bust your enthusiasm, but I had researched all of this and more before writing my original email. It even included the final suggestion of signing the hash of the file because the two things can't be separated (and won't be done anytime soon by the upstream devs). I looked at the agent as the best possibility for this very reason. I also want to make clear as it seems you have taken Denis' word as the gospel here when he mentioned signing package databases. Not a word of what I wrote when starting this thread implied databases, so I apologize for that if it did. Those are no issue at all- they are small enough that we could easily work out a solution similar to what Denis proposed, so we need no remote singing capability at all with those. The only thing I was looking for in this thread was a solution for packages that are too unweildy to schlep back and forth for the sole reason of signing; things like game data, Sage Mathematics packages, OpenOffice, etc. if they were built on a remote machine. It's also nice to link to the full thread if you're going to cross-post one snippet: http://lists.gnupg.org/pipermail/gnupg-users/2011-June/042068.html -Dan
On Mon, Jun 13, 2011 at 12:08 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I also want to make clear as it seems you have taken Denis' word as the gospel here when he mentioned signing package databases. Not a word of what I wrote when starting this thread implied databases, so I apologize for that if it did. Those are no issue at all- they are small enough that we could easily work out a solution similar to what Denis proposed, so we need no remote singing capability at all with those. The only thing I was looking for in this thread was a solution for packages that are too unweildy to schlep back and forth for the sole reason of signing; things like game data, Sage Mathematics packages, OpenOffice, etc. if they were built on a remote machine.
I really messed up the subject of my previous email. Whenever we discussed about remote signing, it was in the context of database signing, so I've took that for granted. I was even intrigued by the fact that you were writing about that in pacman-dev, instead in arch-general, so I really messed up big time. Sorry for that. I'm a little afraid to suggest this, but here we go. Maybe a simpler approach would be to sign only hashes. That way, pacman would always calculate the hash (it already does that for file corruption verification) and see if the signature validates the calculated hash. Makepkg could be updated to calculate a hash and sign it. Pro: unified handling of files and signatures. Con 1: a more convoluted solution, needing some considerable reimplementations and testing. Con 2: it would make harder using gpg directly, as one need to calculate the hash with the correct algorithm before verifing the signature. But this would happen if your original 3) or 4) option is used. But, in the end, it would make easier signing big packages that are built remotely... I'm not very comfortable with my suggestion but I'm doing anyway for the sake of discussion. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Mon, Jun 13, 2011 at 10:08 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Not to bust your enthusiasm, but I had researched all of this and more before writing my original email. It even included the final suggestion of signing the hash of the file because the two things can't be separated (and won't be done anytime soon by the upstream devs). I looked at the agent as the best possibility for this very reason.
I also want to make clear as it seems you have taken Denis' word as the gospel here when he mentioned signing package databases. Not a word of what I wrote when starting this thread implied databases, so I apologize for that if it did. Those are no issue at all- they are small enough that we could easily work out a solution similar to what Denis proposed, so we need no remote singing capability at all with those. The only thing I was looking for in this thread was a solution for packages that are too unweildy to schlep back and forth for the sole reason of signing; things like game data, Sage Mathematics packages, OpenOffice, etc. if they were built on a remote machine.
It's also nice to link to the full thread if you're going to cross-post one snippet: http://lists.gnupg.org/pipermail/gnupg-users/2011-June/042068.html
OK, sorry. I just made a guess as to what you were talking about, since you never transcribed the original conversation or made clear what you were referring to. Anyway, I second Denis's suggestion of always signing the hash rather than the original file. Like I mentioned, any scheme where the signing is done on the server means that keys will get compromised if the main server gets hacked. -Kerrick Staley
participants (4)
-
Dan McGee
-
Denis A. Altoé Falqueto
-
Kerrick Staley
-
Rémy Oudompheng