Re: Proof for a creation date

2016-12-30 Thread Richard Ulrich
Hi Bertram,

sorry for the late answer. 
Blockchain was mentioned in some answers, but nothing in concrete.
Check this out:
https://github.com/opentimestamps

Rgds
Richard

Am Freitag, den 02.12.2016, 03:12 +0100 schrieb Bertram Scharpf:
> Hi,
> 
> 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.
> 
> I could use self-darkening ink but that won't be reflected
> in a JPEG scan and my pen won't make the job that TeX does.
> I could sign a newspapers home page but that cannot be
> reproduced at a later point of time to verify the signature.
> 
> Is there a standard way in GnuPG and in the keyholder
> infrastructure to accomplish this task?
> 
> Thanks in advance.
> 
> Bertram
> 
> 

signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Proof for a creation date

2016-12-07 Thread 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: Proof for a creation date

2016-12-07 Thread 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


Re: Proof for a creation date

2016-12-06 Thread 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

2016-12-06 Thread 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

2016-12-06 Thread 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

2016-12-06 Thread 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

2016-12-06 Thread 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: Proof for a creation date

2016-12-06 Thread 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


Re: Proof for a creation date

2016-12-05 Thread Glenn Rempe


On 12/5/16 4:11 AM, Bertram Scharpf wrote:
> 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.

Posting on a forum or github issue does not provide immutable and
cryptographically verifiable proof that a digest existed at a specific
point in time. It is very weak from that standpoint.

> 
> 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.

If you use one of the services that implants your digest on the
blockchain it is guaranteed to be immutable once transactions are
layered on top of it (within minutes to hours).

This approach does NOT require the service that originally posted this
digest to continue to exist past that point in time as you can
independently verify either the digest or the merkle tree root digest
that you posted using open source software.

As an example, I wrote a Ruby wrapper for the Tierion API and this Ruby
code does not require Tierion to continue to exist past the point when
you retrieve a receipt (which are the merkle tree root verification
instructions that the code can follow). You can verify that a hash
exists in the merkle tree independently and for as long as the
blockchain exists (or as long as you keep your own independent copy of
it). This also provides consensus from thousands of miner machines as to
the rough time when a transaction containing your digest was submitted
since all transactions contain the hash of the prior transactions.
Changing and earlier hash would also require rebuilding all hashes on
top of it which is considered computationally infeasible. This is
similar to how a chain of git commits work, but distributed with real
monetary value on the line. It usually takes about 10-30 minutes from
when you submit the hash to when it is permanently and immutably
embedded in the blockchain.

Tierion is free to use, but requires you to calculate the merkle tree
proof to verify it later (not hard with open source software that is
available). www.proofofexistence.com directly submits your digest on the
blockchain (no merkle tree, your transaction is not shared with other
digests), so it is a bit easier to prove later, but you need to pay them
in BTC to cover the transaction costs and their costs at the time you
make the API call. I think its a couple of dollars worth of BTC.

See
https://github.com/grempe/tierion
https://tierion.com/docs#blockchain-receipts
http://www.chainpoint.org
https://en.wikipedia.org/wiki/Merkle_tree
https://tierion.com/docs/hashapi
https://www.proofofexistence.com

>   - 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.

Not only does itconult.co.uk provide signatures from a key that is no
longer importable in modern GnuPG, you are also relying on the fact that
their system clock is accurate and can never be changed maliciously or
through error. This is not an assumption you can make. There is also no
immutable storage of the hash only a signature that was claimed to be
made at a certain time. A claim that cannot be verified later since it
is lacking context.



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


Re: Proof for a creation date

2016-12-05 Thread Bertram Scharpf
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


Re: Proof for a creation date

2016-12-04 Thread Stephan Beck


MFPA:
> 
> 
> On Friday 2 December 2016 at 1:46:00 PM, in
> , Stephan Beck
> wrote:-
> 
> 
> 
>> gpg's signature timestamp (on a given file) would NOT
>> be a real proof of
>> a document being allegedly signed at that specific
>> date or (prior to a
>> determined date).
> 
> 
> Maybe use a digital timestamping service, such as
> ?
> 
> Or publish an encrypted (or not) copy in the small ads of a newspaper.
> 
> 
> 
Yes, that's it, publish it in the papers. Everyone would agree on that
this would be a "real" proof, i.e. one that would be accepted in the
courtroom.
Luckily, communicating (as via email, as among humans) you do not always
need to have that degree of certainty. :-)

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

2016-12-03 Thread MFPA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Friday 2 December 2016 at 1:46:00 PM, in
, Stephan Beck
wrote:-



> gpg's signature timestamp (on a given file) would NOT
> be a real proof of
> a document being allegedly signed at that specific
> date or (prior to a
> determined date).


Maybe use a digital timestamping service, such as
?

Or publish an encrypted (or not) copy in the small ads of a newspaper.

- --
Best regards

MFPA  

An idealist is a person who helps other people to be prosperous
-BEGIN PGP SIGNATURE-

iL4EARYKAGYFAlhCy71fFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3
MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSHtQEA8/8Lrit4l+I1qgxnCWSov6ai
dF/2/9n31AmG4/0k5HsA/30W1f52Ae3Dmx6B5Gt0DYIXgLDTit8mISD2GvFvHdgN
iQF8BAEBCgBmBQJYQsvOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwNlYIALPOm8l1bgXq1Gn9nuXahN+m
oTKHJMegDoGsYhjDou8YSHHPj998evdAAhsg6yeZwNmq37FRYIyrqx2aMsmQy6qx
lKMyCA0OFDgetFfKS/C/jGkkY0YyZvv5z8mecokmnc82C5T3HpfmzGAazheh+Nm0
SHAp34rkTUL+8zukKbTpnMXhFItlrflThEc4ZoLIj+df7XD3ajWuMgwnf1vEgQY+
CRHCurgWYkVSAEuyqf7ehKhumCfawELbGmfYWQXWpiUfQ9rbRigRQ+OkG/Aw5Ggo
w2HjJI23aAy9ZZRm8T01KYQXR7+0Uy9hyzU+dS1lTZfETtHFdsbHPYqKSyfgzm8=
=7mgK
-END PGP SIGNATURE-


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


Re: Proof for a creation date [GishPuppy]

2016-12-02 Thread Glenn Rempe
Unfortunately, I think the public key from that service is no longer importable 
in modern GnuPG.

https://gnupg.org/faq/whats-new-in-2.1.html#nopgp2

Trying to import the public key on this page results in no public key being 
imported. Without this the service cannot be used to verify the signature on a 
timestamp report (I reported this to them several years ago. No changes were 
made).  Also, this service is not a very secure source of time. They use their 
own clock. They claim some security by using an incrementing counter and 
publishing signed snapshots to a usenet group.  Bottom line though is this 
service is pretty ancient and requires a lot of trust on your part of the 
administrator.

http://www.itconsult.co.uk/stamper/stampinf.htm

$ gpg2 --verbose --import stamper.asc
gpg: armor header: Version: 2.6.3i
gpg: Total number processed: 3
gpg:     skipped PGP-2 keys: 3

$ gpg2 --version
gpg (GnuPG) 2.1.16

> Bertram Scharpf wrote:
>
> > I want to make evidence that I created a document
> > _before_ a certain point of time.
> >
>
>
> http://www.itconsult.co.uk/stamper.htm
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Proof for a creation date

2016-12-02 Thread Glenn Rempe
Tierion creates a Merkle tree of incoming hashes and puts the root of the 
Merkle tree on the Bitcoin blockchain which proves that the hash was placed 
there prior to the time embedded in the BTC transaction. You want to use their 
HashAPI.

https://tierion.com/features

Other similar services are:

http://truetimestamp.org
https://proofofexistence.com

These services don't need GnuPG, but nothing to stop you from hashing a signed 
document.

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


Re: Proof for a creation date [GishPuppy]

2016-12-02 Thread gmane . bl4
Bertram Scharpf wrote:

> I want to make evidence that I created a document
> _before_ a certain point of time.
>


http://www.itconsult.co.uk/stamper.htm


Gishpuppy | To change the delivery settings for this email, click here: 
http://www.gishpuppy.com/cgi-bin/edit.py?email=gmane@gishpuppy.com

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


Re: Proof for a creation date

2016-12-02 Thread Brian Minton
On Fri, Dec 02, 2016 at 01:37:00PM +0800, Quan Zhou wrote:
> so GnuPG's timestamping isn't an option for this?
> Even X509 has a timestamping feature for this kind of use.
> 

No, because you could just set your computer's clock to anything you want,
then create the GnuPG /X509 timestamp.  

I agree with some of the other posters; the best way is to either post the
whole message, or a cryptographically strong hash of it to some public
append-only location, and the Bitcoin blockchain or a certificate transparency
log both do it the same way, via a cryptographic hash inserted into a Merkle
tree.  That has the desired properties of being append-only and publicly
auditable.

-- 
Brian Minton
brian at minton dot name http://brian.minton.name
Live long, and prosper longer!
OpenPGP fingerprint = 8213 71DD 4665 CF4F AE20  2206 0424 DC19 B678 A1A9


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


Re: Proof for a creation date

2016-12-02 Thread Stephan Beck
Hi Quan Zhou,

Quan Zhou:
> so GnuPG's timestamping isn't an option for this?
> Even X509 has a timestamping feature for this kind of use.
> 
> On Fri, Dec 2, 2016 at 11:59 AM, Schlacta, Christ 
> wrote:
> 
>> The easiest way is to publish your code to a publicly controlled source
>> with a signature on or before your desired date. Not sure if there's a
>> *better* way.
>>
>> On Dec 1, 2016 7:43 PM, "Bertram Scharpf" 
>> wrote:
[...]
>>> I want to do the opposite. I want to make evidence
>>> that I created a document _before_ a certain point of time.
[...]
>>> Is there a standard way in GnuPG and in the keyholder
>>> infrastructure to accomplish this task?

since it is possible to fake system time by modifying system time in
BIOS (all OS with BIOS or similar) and (on GNU/Linux systems) by using
faketool application-wide, or, more specifically, gpg's
--fake-system-time EPOCH (usable from 2.1 on if gnupg was compiled using
debug flags; although this option is documented for previous versions as
to the 2.0.x manpages or the gnupg's info manual, it only is implemented
and usable in gpg 2.1. see (1)(2)(3)(4)

gpg's signature timestamp (on a given file) would NOT be a real proof of
a document being allegedly signed at that specific date or (prior to a
determined date). So it would NOT either be a credible proof of a
document being allegedly created before a determined date, if you
decided to sign it immediately after creating it in order to document
its creation date via signature time).

Cheers

Stephan

(1) https://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028724.html
(2) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760354
(3)
https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2014-September/001774.html
(4) https://marc.info/?l=gnupg-commit-watchers=146009708822599=2


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

2016-12-01 Thread Quan Zhou
so GnuPG's timestamping isn't an option for this?
Even X509 has a timestamping feature for this kind of use.

On Fri, Dec 2, 2016 at 11:59 AM, Schlacta, Christ 
wrote:

> The easiest way is to publish your code to a publicly controlled source
> with a signature on or before your desired date. Not sure if there's a
> *better* way.
>
> On Dec 1, 2016 7:43 PM, "Bertram Scharpf" 
> wrote:
>
>> Hi,
>>
>> 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.
>>
>> I could use self-darkening ink but that won't be reflected
>> in a JPEG scan and my pen won't make the job that TeX does.
>> I could sign a newspapers home page but that cannot be
>> reproduced at a later point of time to verify the signature.
>>
>> Is there a standard way in GnuPG and in the keyholder
>> infrastructure to accomplish this task?
>>
>> Thanks in advance.
>>
>> 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
>
>


-- 
Regards,

Quan Zhou
++
|pub [expires 2019-05-04]|
|D7CF DCE8 2EBA 2766 499A|
|20DF 8273 6C6F ABCD 0A0F|
++
|pub [revoked 2016-04-16]|
|44D2 0307 1643 E80F 2E31|
|F081 FAFA 6643 7F9F D46F|
++
|quanzhou...@gmail.com   |
|https://keybase.io/qzhou|
++
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Proof for a creation date

2016-12-01 Thread Schlacta, Christ
The easiest way is to publish your code to a publicly controlled source
with a signature on or before your desired date. Not sure if there's a
*better* way.

On Dec 1, 2016 7:43 PM, "Bertram Scharpf"  wrote:

> Hi,
>
> 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.
>
> I could use self-darkening ink but that won't be reflected
> in a JPEG scan and my pen won't make the job that TeX does.
> I could sign a newspapers home page but that cannot be
> reproduced at a later point of time to verify the signature.
>
> Is there a standard way in GnuPG and in the keyholder
> infrastructure to accomplish this task?
>
> Thanks in advance.
>
> 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


Re: Proof for a creation date

2016-12-01 Thread Daniel Kahn Gillmor
On Thu 2016-12-01 21:12:50 -0500, Bertram Scharpf wrote:
> I want to make evidence that I created a document _before_ a certain
> point of time.

One approach i've seen recommended is to create a
cryptographically-strong digest of the signed document in question and
then post it to a public, append-only log somewhere.

For example, take the SHA256 digest of the document, pretend that value
is the address of a bitcoin wallet, and throw a little bit of bitcoin
into it (this value will never be recoverable because no one knows the
corresponding secret key). This puts the digest into the blockchain at a
acertain date for anyone to see.

Your subsequent argument is that one of the two possibilities must hold:

 (a) you have some ability to perform a collision attack against
 SHA-256, or

 (b) the signed document existed at some point before the bitcoin
 transaction was publicly logged.

since most people won't believe (a), (b) looks pretty likely.

You could use any other globally-visible log that allows for injection
of a bitstring long enough for a strong digest (32 octets is probably
sufficient), it doesn't have to be the bitcoin blockchain.  for example,
if you can get something into a public X.509 certificate, you could post
it to one of the certificate transparency logs.

Regards,

--dkg


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


Proof for a creation date

2016-12-01 Thread Bertram Scharpf
Hi,

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.

I could use self-darkening ink but that won't be reflected
in a JPEG scan and my pen won't make the job that TeX does.
I could sign a newspapers home page but that cannot be
reproduced at a later point of time to verify the signature.

Is there a standard way in GnuPG and in the keyholder
infrastructure to accomplish this task?

Thanks in advance.

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