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