-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2011 08:13 PM, Robin H. Johnson wrote: > On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: >> 3) Rely on an existing key list somewhere distributed in portage; the list >> file with the key id's (not the keys themselves) is signed with a master key. >> Is a mediocre and potentially insecure workaround. >> Pros: you can exactly decide what keys are used and trusted, without >> thinking >> about GnuPG's inner workings. A user can edit his key and the key remains >> trusted. >> Cons: Mainly that the key id is a pretty short hash afaik.(Any >> better-informed >> people around?) > 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) > 2. Clear-sign L, produces L' > 3. Include L' in /metadata/ during rsync content build. > 3.1. Provide all L' files in a trusted Git repository for historical > reference. > 4. Tree-sign per GLEP58, such that signed list is included. > > Pros: > - L' is plaintext and works well w/ rsync deltas. > > Security weakpoints: > - Introduces new weak point if attacker can compromise the automated > clear-signing service of #2. > >> 4) Rely on an existing list of keys somewhere distributed in portage and >> possibly somewhere else (keyservers); a key userid is signed with a master >> key. Work with GnuPG's well-tested and well-thought-out trust relationships. >> Back to start, time to re-read the entire thread... :) > What does this actually add over #3 in terms of security? >
This is an extremely non-trivial question. You're talking about signing each individual key's fingerprint vs generating a list of key fingerprints (hashes of the key), concatenating them all, hashing THAT, and then signing that hash. - From a cryptologic point of view, I would be *extremely* impressed with anyone that can find a proof of security that shows that those two are equivalent. Simple(ish) example. By creating a list you're introducing a lot of data that is then getting hashed. Now, from a cryptologic point of view, I would *not* attack the signature per se, but rather the underlying hash of the list. By providing a large file with lots of data, there are attacks against (some) has functions that can make use of this (Small changes in the file that will result in the same hash with probability greater than normal). (Anyone know off the cuff what hash is actually used?) Now, the other method would require having to single out each hash on it's own, and the underlying key that it hashed. That data is harder to deal with because you have to manipulate one key into another *valid* key(a difficult task to have it still be valid) and have it come out with the same hash. Whereas with the file, who cares if they invalidate another key, as long as they can get their hash into the file and have the hash for the sig come out the same. Point being, what it adds / subtracts is not a simple question. Crypto is a funny beast, and is best not trifled with unless you understand the underlying math / the current attacks etc (And even then, don't do it =P). Do I think that using #4 gives us a huge difference over #3, even with my years of study on this topic I would not even begin to try to answer that. Chances are the difference is negligible for our *needs* (see below), but I don't think it's negligible in the true sense of security. Having said that we aren't exactly talking about securing the end all be all. We just want to be able to verify with a reasonable degree of certainty that the tree is in a good state and that it wasn't tampered with. Do we really need the end all be all, I somehow doubt it. - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNkLnkAAoJEEsurZwMLhUxV64P/1AbiEkcbouFd/XZ50aq/BsC LRjlUC5GbCpBL1MBTigP1OWO0HT8JvBEKJPAbwChr+KSQqtk3/HOcaoRTlJDz3hf iG7NrKkh4VECwErshFpzS1/D0D7M2qFXABat7DE/lPmFrIpI96XSd+ZAnjLMtM0g RoFOAyJ3s3CEIKeG3n448TQagpHkAGinzgkmtA8NZRUf/ziukA7Gk7lQGC+e9YIE MViWW4bBB1PQq4XL5in58JH2ohQBx49+RgeovdREnTWFJlDsHbxIZN3JTV8EHq7a 8xpni/uPLCbW3XGS2G3x/L7f8yPJOqEyTPROU3s+YGDtZkDYwDI1bn+k2Fnu+3a7 kkFyp4aRrajiFE4WK20iBnnPJn1knfR47O6UEP4aZu/GCC3s/3fJP5pVNlnla7mU 5RXJ1j6Tj3MQoCBdbGypEaVYJf1ZiJGdpUYOHpi4XL2R3mh8XsmnEF53pdp7GOk/ wHfuKvvZ5uKtYawj8QhVB8+Y97kTNYc7t7OIShpAZb0SoyUN+ZGoal4pDASkSM15 uATdmilb7z5JIEKiQ0lLwjdLjJJq5imgpB4YuQBqiF3sKmH8N9Qf5+kCRxvSE09y lq1hWqppGX+H4CvA5FPRkB7/Qvg2prmwfdIqDlGWfMlR2KLsFoIzRyjKnL1xSCgn eX/hTD9umMkzOho7l1eL =h4nm -----END PGP SIGNATURE-----
