Re: Hybrid keysigning party, your opinion?

[Stephan Beck]

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

[Robert J. Hansen]

> 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

[NdK]

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

[Stephan Beck]

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

[Andrew Gallagher]

> 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