Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
software:pgp [2022/04/08 00:17] cyril add much more information about trusted timestamping |
software:pgp [2022/04/08 00:24] cyril more fixes |
||
---|---|---|---|
Line 23: | Line 23: | ||
Remarks: | Remarks: | ||
- | * Providing only a cryptographically secure hash of your data instead of the whole data is sufficient, | + | * Providing only a cryptographically secure hash of your data instead of the whole data is sufficient, while ensuring confidentiality of your data. |
- | | + | * If you also want to prove that you were in possession of this document at this time (i.e. that you did not find it with the trusted timestand later), you need to make sure that it is clearly written in the document that you are its author. You can also create an intermediate file containing both your name as well as the file hash. However you still benefit from plausible deniability (someone else cannot prove that you are the author), as anyone could have proceeded to this trusted timestamping with your name in it. |
- | * If you also want to prove that you were in possession of this document at this time (i.e. that you did not | + | * If you want a bit stronger proof that you were in possession of this document at this time, and accept non-repudiation (or it is demanded by a third party), you can also include a signature of the document with your PGP key in the intermediate file. |
- | | + | * Note: if you don't want to decide whether signing or not when timestamping, |
- | | + | * If you need to timestamp multiple files, you can write the hash of the different files in the intermediate file, and timestamp this intermediate summary file. You could also zip the files and timestamp the zip file, but it would force you to divulgate all the files for verification, |
- | | + | * If you need to encrypt the data, for instance for backup purposes, you may want to timestamp the unencrypted data, in order to avoid having to divulgate the decryption key for verification (especially if it is a private key), or allow to change the key for the transfer. |
- | | + | * If you want long term validity (after certificates are expired or revoked), you should store the TSA certificates used (whole chain). |
- | * If you want a bit stronger proof that you were in possession of this document at this time, and accept | + | * If the TSA has its private key compromised, |
- | | + | * make multiple timestamps from different services (this is what is advised in 4.2 of RFC 3161). It is parallel timestamping. |
- | | + | * make recursively chaining timestamps from different services (it recursively proves that the previous timestamp has not been antidated). It is serial timestamping. |
- | | + | * make multiple timestamps from different services, then immediately create a new summary file for all these timestamps, and timestamp it again with the different services. It does not bring additional security in theory, but combines both parallel and serial timestamping, |
- | create two versions of the intermediate file, with and without signatures, and timestamp both. | + | * note: when serial timestamping, |
- | However it has limited value, as | + | * note: mixing different hash algorithms may also be interesting. |
- | plausible deniability only makes sense if someone else obtains the files and opposes them to you, | + | * Actually, trusted timestamping is also a good way to ensure the long term validity of a signature, by proving that it was made during the validity period of the key. |
- | so the mere existence of non-repudiable signatures opens this risk. Divulgating yourself the | + | * It also seem that when the TSA certificate expires, the timestamp expires as well, and you need to periodically re-timestamp the timestamps (recursively) to extend its validity (4.3 of RFC 3161). Re-timestamping (with more recent algorithm) can also protect against the original algorithm becaming vulnerable. This would be very rare though, as crypto-hash algorithms usually only become vulnerable to collisions, but not to preimage, and even in this case it would be still extremely complicated to generate a different preimage that looks plausible, without hidden random garbage. At large scale, RFC 4998 for Evidence Records describes how to optimize the timestamps renewal with a tree. |
- | deniable files, realizing that you should not have, and ending up denying them, would be very suspicious | + | |
- | (except maybe saying that the files were altered by someone else, | + | |
- | but you would have to provide the unaltered files, with which you initially got mixed up). | + | |
- | * If you need to timestamp multiple files, you can write the hash of the different files in the intermediate | + | |
- | | + | |
- | | + | |
- | | + | |
- | * If you need to encrypt the data, for instance for backup purposes, you may want to timestamp the | + | |
- | | + | |
- | | + | |
- | * If you want long term validity (after certificates are expired or revoked), | + | |
- | | + | |
- | * If the TSA has its private key compromised, | + | |
- | | + | |
- | | + | |
- | | + | |
- | It is parallel timestamping. | + | |
- | | + | |
- | the previous timestamp has not been antidated). | + | |
- | It is serial timestamping. | + | |
- | | + | |
- | summary file for all these timestamps, and timestamp it again with the different services. | + | |
- | It does not bring additional security in theory, but combines both parallel and serial timestamping, | + | |
- | at the cost of twice as much timestamps. | + | |
- | If you want to limit the number of timestamps, you can use half of them at each step. | + | |
- | | + | |
- | and the second summary file also link to the data, and maybe even the CRL (Certificate Revocation List). | + | |
- | | + | |
- | * Actually, trusted timestamping is also a good way to ensure the long term validity of a signature, by proving that | + | |
- | | + | |
- | * It also seem that when the TSA certificate expires, the timestamp expires as well, and you need | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
Line 93: | Line 56: | ||
Free services (as of 2022): | Free services (as of 2022): | ||
* Certified in France or Europe: | * Certified in France or Europe: | ||
- | | + | * N/A |
* TSA with accuracy and chainable to ubiquously trusted certificate (all trust stores): | * TSA with accuracy and chainable to ubiquously trusted certificate (all trust stores): | ||
- | | + | * GlobalSign ([[http:// |
- | RFC 3161 from TSQ, sha512, accuracy 1s | + | * Certum ([[http:// |
- | | + | |
- | RFC 3161 from TSQ or hash, sha512, accuracy 1s | + | |
* TSA that can be chained to somewhat trusted certificate (some trust stores), or don't provide accuracy information: | * TSA that can be chained to somewhat trusted certificate (some trust stores), or don't provide accuracy information: | ||
- | | + | * DigiCert ([[https:// |
- | RFC 3161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate | + | * EnTrust ([[http:// |
- | | + | * Comodo / Sectigo / USERTrust ([[http:// |
- | RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate | + | * Apple ([[http:// |
- | | + | * Symantec / VeriSign ([[http:// |
- | RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate (failing to verify for unknown reasons though) | + | |
- | | + | |
- | RFC 3161 from TSQ, sha512, accuracy 1s | + | |
- | | + | |
- | RFC 3161 from TSQ, sha512, accuracy 30s, signed by VeriSign root, sold to symantec in 2010, then sold to broadcom, root not distributed anymore | + | |
* Independent party: | * Independent party: | ||
- | | + | * FreeTSA ([[https:// |
- | RFC 3161 from TSQ, sha512, no accuracy, self-signed certificate | + | * ItConsult ([[http:// |
- | | + | |
- | PGP signature with index by email | + | |
Limited services: | Limited services: | ||
- | * TrueTimestamp ([[http:// | + | * TrueTimestamp ([[http:// |
- | | + | * DigiStamp ([[https:// |
- | * DigiStamp ([[https:// | + | |
- | | + | |
Services With free trial duration: | Services With free trial duration: |