Re: Proof for a creation date

[NdK]

Il 07/12/2016 00:27, Andrew Gallagher ha scritto:

> I don't see any reason why it couldn't be done in principle - anyone who 
> wants could set up an "authority" that produces a regular, signed list of all 
> the certificates it currently trusts at each point in time. The trick is a) 
> making sure that revocations get submitted to the authority in a timely 
> fashion and b) working out whether to trust the authority in the first place. 
> But that's a problem in OCSP too. 
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".
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.

> In general, anything you can do in the X509 trust model you can do in PGP - 
> but with a little more effort and a lot fewer default assumptions. 
That's good: this way most "implicit assumptions" must be explicited and
their security impatc must be evaluated.

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Proof for a creation date

[Andrew Gallagher]

I don't see any reason why it couldn't be done in principle - anyone who wants 
could set up an "authority" that produces a regular, signed list of all the 
certificates it currently trusts at each point in time. The trick is a) making 
sure that revocations get submitted to the authority in a timely fashion and b) 
working out whether to trust the authority in the first place. But that's a 
problem in OCSP too. 

In general, anything you can do in the X509 trust model you can do in PGP - but 
with a little more effort and a lot fewer default assumptions. 

Andrew Gallagher

> On 6 Dec 2016, at 22:57, NdK  wrote:
> 
> Il 06/12/2016 23:14, Andrew Gallagher ha scritto:
> 
>>> That could actually reduce trust in any PGP signature, unless there's a
>>> way to timestamp 'something' that says "as of 'now' this key have not
>>> been revoked". Ideally that attestation should be included with the 
>>> signature itself
>> So, essentially OCSP?
> That's the idea, but in GPG trust model... Is it possible?
> 
> BYtE,
> Diego
> 


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Proof for a creation date

[NdK]

Il 06/12/2016 23:14, Andrew Gallagher ha scritto:

>> That could actually reduce trust in any PGP signature, unless there's a
>> way to timestamp 'something' that says "as of 'now' this key have not
>> been revoked". Ideally that attestation should be included with the 
>> signature itself
> So, essentially OCSP?
That's the idea, but in GPG trust model... Is it possible?

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Proof for a creation date

[Andrew Gallagher]

So, essentially OCSP?

Andrew Gallagher

> On 6 Dec 2016, at 21:42, NdK  wrote:
> 
> That could actually reduce trust in any PGP signature, unless there's a
> way to timestamp 'something' that says "as of 'now' this key have not
> been revoked". Ideally that attestation should be included with the signature 
> itself


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Proof for a creation date

[NdK]

Il 06/12/2016 12:30, Roman Zeyde ha scritto:
> You can also use OpenTimestamps service as described here:
> https://petertodd.org/2016/opentimestamps-announcement
Interesting!

To remain on-topic, I'd like to take the "footnote 3":
-8<--
An interesting nuance to this is someone who has stolen a PGP key could
also create a revocation, and they could backdate it to deny access to
previously created signatures; there’s a lot of interesting design
questions about how to deal with this with random beacons and the like
that are beyond the scope of this blog post
-8<--

That could actually reduce trust in any PGP signature, unless there's a
way to timestamp 'something' that says "as of 'now' this key have not
been revoked". Ideally that attestation should be included with the
signature itself.

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.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
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]

Carola Grunwald:
> Peter Lebbing wrote:
>> On 25/11/16 00:03, Carola Grunwald wrote:

[...]
>> An option --only-try-secret  would solve both (your software
>> would know which to try for a given nym account), but such an option is
>> not available. You could try to make the case that such an option would
>> be a good idea to implement. It would serve more scenarios than just
>> yours. For instance, people with smartcards could use it when a message
>> is also encrypted to an on-disk key, when they can't or don't want to
>> insert their smartcard. And if somebody knows which key is the hidden
>> recipient, but has multiple secret keys, it would save them declining
>> all the dialogs for the keys that aren't the recipient.
> 
> I'm not sure whether gpg.exe can handle the concatenation of dozens of
> '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227' parameters
> and stop using keys not on that list even with their passphrases in the
> cache.

If you created a special (secret) keyring file (being encrypted to your
server's subkey as an additional security measure) containing all secret
keys you'd need to have in there (=all those keys your particular agent
instance has to serve), 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? Would that be feasible?
This option should be available for GNuPG's Windows version as well. (I
understand that you're in a Windows (server) environment and are talking
about gpg4win, are you?)
Wouldn't gpg 2.1 then just use this one and only key for decryption
(which is part of that secret keyring file) and, otherwise (if this key
fails to decrypt), give up on decrypting?

I can't reproduce your environment right now, so I can't try it out,
it's just a guess.

Cheers

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

[Roman Zeyde]

You can also use OpenTimestamps service as described here:
https://petertodd.org/2016/opentimestamps-announcement

On Mon, Dec 5, 2016 at 2:11 PM, Bertram Scharpf 
wrote:

> On Thursday, 01. Dec 2016, 19:59:15 -0800, Schlacta, Christ wrote:
> > On Dec 1, 2016 7:43 PM, "Bertram Scharpf" 
> wrote:
> > >
> > > we all know that kidnappers do publish a picture of their
> > > hostage holding up a todays newpaper. The purpose of this is
> > > to proof that the victim was alive _after_ a certain point
> > > of time. I want to do the opposite. I want to make evidence
> > > that I created a document _before_ a certain point of time.
>
> Thank you all for your detailed answers.
>
> I might resume it to two possibilities to accomplish the task:
>
>   - Post a digest to a site where you cannot withdraw it
> ever and where it can be retrieved by everybody. This
> could be a Github issue, on Reddit or Twitter or maybe
> even on the GnuPG mailing list.
>
> The disadvantage is that you are dependent on the
> provider of the site to continue the service and that
> your information can be found there. This could most
> notably become a problem because the post is, in the
> end, an abuse of the forum.
>
>   - Let one or more people sign your document and provide
> the signatures yourself.
>
> The weak point is how to find these people and to make
> them do what you want. The service
>  makes
> signatures in a format that is no longer supported.
>
> Maybe a combination of both methods is a good way to handle
> the disadvantages.
>
> Bertram
>
>
> --
> Bertram Scharpf
> Stuttgart, Deutschland/Germany
> http://www.bertram-scharpf.de
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users