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
