Re: Hybrid keysigning party, your opinion?
Peter Lebbing: > Hi all, > > In just a few weeks, the 33C3 will be held in Hamburg, the 33th Chaos > Communication Congress organized by the Chaos Computer Club. I intend to > organize a keysigning party, just because they are fun. > > I am asking for your thoughts on a variant of the organization of the > keysigning party. ... Doesn't your proposal imply that late attendees could make their way through all the keysigning without fingerprint verification? Or do I miss something? Cheers Stephan Thank you in any case for your detailed information, that encouraged me to install the keysigning package and have a look into it. It seems to be a great tool for organizing a key-signing event! 0x4218732B.asc Description: application/pgp-keys 0x4218732B.asc Description: application/pgp-keys 0x4218732B.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: RFC on issue 2701, default expiration time for new keys
> I'd not say "THE best practices document", but rather "A RANDOM best > practices document someone wrote". There are lots of those, and can freely > be ignored, IMNSHO. I'd go one step further: this is not even a best-practices document. Any document which claims to be a best-practices document which does not have, as a high-priority item, "Figure out your threat model," is frankly just somebody pretending to be competent. [puts on FAQ maintainer hat] Every now and again I get someone asking me why there aren't best practices listed in the FAQ. The answer is always the same: because GnuPG doesn't really have them. GnuPG is a toolkit you use to implement part of your custom solution to address your particular threat model. As such, the idea of "best practices" that are one-size-fits-all is really kind of silly. There might be some merit in a "Things To Think About" document, but the idea of a single best-practices document that applies to everyone everywhere borders on the absurd. [takes off hat] > This document also recommends creating a 4K RSA key. And it complicates > matters by strongly recommending installing parcimonie and Tor over just > using --refresh-keys. That's one more hurdle for users to overcome in an > already very complicated matter, and as such, IMNSHO, it is actually > hindering user adoption. It also recommends ignoring things like the keyserver-url field on a certificate. Which is ... interesting. If Alice works for a company that's rolled out GnuPG, the company may have its own LDAP server with up-to-the-minute revocations. And the company may wish you to fetch Alice's certificate from it, in order to get up-to-the-minute details, as opposed to getting it from the keyserver network, which the company doesn't sync with. So if you follow these "best practices", you'll actually never get to update Alice's certificate, even when it's revoked after she leaves the company... Also, don't get me started on "Primary keys should be DSA2 or RSA (RSA preferred)". Right, like there's some inherent problem with DSA2 that makes RSA such a superior choice... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proof for a creation date
Il 07/12/2016 09:53, Andrew Gallagher ha scritto: > No signature can possibly attest that something is valid *forever*. Well, "till the heat death of the Universe" can be enough for any practical purpose :) > You're right that stapling is absolutely required in a data at rest > use case, because a real time service only makes sense for ephemeral > comms. But it's just a form statement by the authority which the > sender appends to their signed data. My aim is something that's still secure even if some big leaps happen. Say QC becomes feasible: current pki methods (RSA and EC) are to be considered insecure. Hence I included a PQ signature (maybe NewHope?). > Trying to protect against future compromise of a signature algorithm is > really hard. And once you open that door, all data at rest signatures > are questionable. Well, actually symmetric crypto could be used with a system like the one used for one-time signatures: you sign both the (hash of the ) plaintext and the hash of the cyphertext obtained encrypting that plaintext with a (randomly generated, single use) secret key. This system allows a single arbitration: you give the judge the secret key used and he verifies that: a) the hash on the plaintext matches the signed one (everyone ca do this) b) the hash on the cyphertext matches the signed one (everyone ca do this, too) c) the hash of the plaintext encrypted under the given key matches b) A timestamping service could easily generate such a key from a "really secret key" (never disclosed) and the timestamp, maybe using a truncated hash (to prevent a possible hash inversion attack to determine the "really secret key") and remain able to disclose it to the judge without compromising other signatures' security. An attacker should be able to find another (meaningful!) messages that hashes to the same value and whose cyphertext under an unknown key would result in the other hash value. H(p')==H(p) H(Ek(p'))==H(Ek(p)) (for every k, since he does not know k) > Merkle trees protect against this though, as not only do you have to > forge the signature, but also recreate the entire subsequent merkle > tree, which should be infeasible. IIUC, merkle trees remain secure only if they continue to "evolve". If an attacker does have enough (more than 50%) computing power, he can control the tree's growth. And possibly rewrite the history (IIRC something similar happened not long ago, when a single group of miners had had for some hours the needed "quorum"). > If you embed the OCSP response in the tree with the signed data, then > it enjoys the same protection. I have to think about this a bit more... I'm not completely sure. To be at least partially in topic, it should be possible to do the signing (and the encryption) even with the current GnuPG version... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Implications of a common private keys directory in 2.1
Peter Lebbing: > On 06/12/16 15:53, Stephan Beck wrote: >> [...], and use it as in >> gpg2 --no-default-keyring --secret-keyring file --try-secret-key >> [NAME=aspecificlongKeyID | fingerprint] --decrypt >> any_signedANDencrypted_message.txt.gpg ? >> Would that work? > >>From the GnuPG 2.1 man page: > >--secret-keyring file > This is an obsolete option and ignored. All secret keys > are > stored in the ‘private-keys-v1.d’ directory below the GnuPG > home > directory. > > GnuPG 2.1 works in a different way with secret key material, so you can't > have multiple secret keyrings in the same homedir anymore. Oh, I missed this point. Thanks for putting it right. And it's more, no code left in gpg 2.1 for handling (secret) key material. Another mistake is (from what I have learned now) that you can only apply --try-secret-key together with --hidden-recipients. Anyway, if there was an "!" option as in --export-secret-subkeys keyID! you would be able to indicate/convince/force gpg 2.0.x to use a particular (sub)key. But I think this only refers to the case of having several subkeys, and at the moment of exporting one of them. And it's a 2.0.x option, I haven't checked the 2.1 manual for this particular option yet, though. Thanks Stephan 0x4218732B.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proof for a creation date
> On 7 Dec 2016, at 05:50, NdK wrote: > > The "stapling" part is the hardest, since with OCSP usually you need to > verify that something is valid "now", while with a GPG signature you > should be able to attest that something will be valid "forever". No signature can possibly attest that something is valid *forever*. You're right that stapling is absolutely required in a data at rest use case, because a real time service only makes sense for ephemeral comms. But it's just a form statement by the authority which the sender appends to their signed data. > The only way to obtain that (I can think of, and assuming no online > verification: online services come & go...) is having at least three > different kind of keys (RSA, EC, PQ) sign at least three different hash > function results *each*, so that even if an algorithm or two gets > cracked the signature remains valid. Trying to protect against future compromise of a signature algorithm is really hard. And once you open that door, all data at rest signatures are questionable. Merkle trees protect against this though, as not only do you have to forge the signature, but also recreate the entire subsequent merkle tree, which should be infeasible. If you embed the OCSP response in the tree with the signed data, then it enjoys the same protection. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users