[[software:pgp]]
Trace:
Show page
AdminRecent ChangesSitemap

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
software:pgp [2022/04/08 00:17]
cyril add much more information about trusted timestamping 		software:pgp [2022/04/24 15:23] (current)
cyril [Trusted Timestamping]
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. 
-    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 it was not done by someone else, and you found it with the trusted timestamp 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. 
-    find it with the trusted timestand later), you need to make sure that it is clearly written in the document +    * Note: if you don't want to decide whether signing or not when timestamping, you could create two versions of the intermediate file, with and without signatures, and timestamp both. However it has limited value, as plausible deniability only makes sense if someone else obtains the files and opposes them to you, so the mere existence of non-repudiable signatures opens this risk. Divulgating yourself the 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). 
-    that you are its author. You can also create an intermediate file containing both your name as well as the +  * 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, even if you don't need or want to. 
-    file hash. However you still benefit from plausible deniability (someone else cannot prove that you are the +  * 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.  
-    author), as anyone could have proceeded to this trusted timestamping with your name in it. +  * 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, it will be revoked, but can be used to forge antidated timestamps, annihilating the value of all the past timestamps that have been made. In order to be protected against that event, you can: 
-    non-repudiation (or it is demanded by a third party), you can also include a signature of the document +    * make multiple timestamps from different services (this is what is advised in 4.2 of RFC 3161). It is parallel timestamping. 
-    with your PGP key in the intermediate file. +    * make recursively chaining timestamps from different services (it recursively proves that the previous timestamp has not been antidated). It is serial timestamping. 
-    ** Note: if you don't want to decide whether signing or not when timestamping, you could +    * 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, 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. 
-       create two versions of the intermediate file, with and without signatures, and timestamp both. +    * note: when serial timestamping, the TSA certificate needs to be included in the timestamp though, and the second summary file also link to the data, and maybe even the CRL (Certificate Revocation List). 
-       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 +
-    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, even if you don't need +
-    or want to. +
-  * 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 the TSA has its private key compromised, it will be revoked, but can be used to forge antidated timestamps, +
-    annihilating the value of all the past timestamps that have been made. In order to be protected against that +
-    event, you can: +
-    ** 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, +
-       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. +
-    ** note: when serial timestamping, the TSA certificate needs to be included in the timestamp though, +
-       and the second summary file also link to the data, and maybe even the CRL (Certificate Revocation List). +
-    ** note: mixing different hash algorithms may also be interesting. +
-  * 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. +
-  * 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.+
  
  
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+    * 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://rfc3161timestamp.globalsign.com/advanced|server]]): +    * GlobalSign ([[http://rfc3161timestamp.globalsign.com/advanced|server]]): RFC 3161 from TSQ, sha512, accuracy 1s 
-       RFC 3161 from TSQ, sha512, accuracy 1s +    * Certum ([[http://time.certum.pl/|server]]): RFC 3161 from TSQ or hash, sha512, accuracy 1s
-    ** Certum ([[http://time.certum.pl/|server]]): +
-       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://knowledge.digicert.com/generalinformation/INFO4231.html|infos]], [[http://timestamp.digicert.com/|server]]): +    * DigiCert ([[https://knowledge.digicert.com/generalinformation/INFO4231.html|infos]], [[http://timestamp.digicert.com/|server]]): RFC 3161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate 
-       RFC 3161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate +    * EnTrust ([[http://timestamp.entrust.net/TSS/RFC3161sha2TS|server]]): RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate 
-    ** EnTrust ([[http://timestamp.entrust.net/TSS/RFC3161sha2TS|server]]): +    * Comodo / Sectigo / USERTrust ([[http://timestamp.comodoca.com|server]]): RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate (failing to verify for unknown reasons though) 
-       RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate +    * Apple ([[http://timestamp.apple.com/ts01|server]]): RFC 3161 from TSQ, sha512, accuracy 1s 
-    ** Comodo / Sectigo / USERTrust ([[http://timestamp.comodoca.com|server]]): +    * Symantec / VeriSign ([[http://sha256timestamp.ws.symantec.com/sha256/timestamp|server]]: RFC 3161 from TSQ, sha512, accuracy 30s, signed by VeriSign root, sold to symantec in 2010, then sold to broadcom, root not distributed anymore
-       RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate (failing to verify for unknown reasons though) +
-    ** Apple ([[http://timestamp.apple.com/ts01|server]]): +
-       RFC 3161 from TSQ, sha512, accuracy 1s +
-    ** Symantec / VeriSign ([[http://sha256timestamp.ws.symantec.com/sha256/timestamp|server]]: +
-       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://www.freetsa.org/index_en.php|infos]], [[https://freetsa.org/tsr|server]]): +    * FreeTSA ([[https://www.freetsa.org/index_en.php|infos]], [[https://freetsa.org/tsr|server]]): RFC 3161 from TSQ, sha512, no accuracy, self-signed certificate 
-       RFC 3161 from TSQ, sha512, no accuracy, self-signed certificate +    * ItConsult ([[http://www.itconsult.co.uk/stamper.htm|infos]]): PGP signature with index by email
-    ** ItConsult ([[http://www.itconsult.co.uk/stamper.htm|infos]]): +
-       PGP signature with index by email+
  
 Limited services: Limited services:
-  * TrueTimestamp ([[http://truetimestamp.org/|infos)]]: +  * TrueTimestamp ([[http://truetimestamp.org/|infos)]]: RFC 3161 by form, and by URL 5/day, sha256, not tested 
-    RFC 3161 by form, and by URL 5/day, sha256, not tested +  * DigiStamp ([[https://www.digistamp.com/|infos]]): account, 25/year free
-  * DigiStamp ([[https://www.digistamp.com/|infos]]): +
-    account, 25/year free+
  
 Services With free trial duration: Services With free trial duration:
software/pgp.1649377039.txt.gz · Last modified: 2022/04/08 00:17 by cyril
Show pageOld revisions
Media ManagerBack to top
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0