Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Next revision Both sides next revision | ||
software:pgp [2022/04/08 00:16] cyril enterinate last external modif from 2013 |
software:pgp [2022/04/08 00:17] cyril add much more information about trusted timestamping |
||
---|---|---|---|
Line 17: | Line 17: | ||
For emails, you should use some software to automatically manage your keyring and sign, verify signatures, encrypt and decrypt messages, like the Enigmail addon with Thunderbird. | For emails, you should use some software to automatically manage your keyring and sign, verify signatures, encrypt and decrypt messages, like the Enigmail addon with Thunderbird. | ||
- | ===== Trusted | + | ===== Trusted |
- | If a trusted third party signs with its private key a document of yours, then it will prove the integrity and the timestamp of your document. | + | If a trusted third party signs with its private key a document of yours and a timestamp issued by them, |
+ | then it will prove that the document | ||
- | There are a few working and easy enough | + | Remarks: |
- | * [[https://www.universign.eu/]]: legally certified, you have 10 free seals. Size limited. | + | * Providing only a cryptographically secure hash of your data instead of the whole data is sufficient, |
- | * [[http://www.itconsult.co.uk/stamper.htm]]: probably | + | 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 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, | ||
+ | | ||
+ | | ||
+ | | ||
+ | so the mere existence of non-repudiable signatures opens this risk. Divulgating yourself the | ||
+ | | ||
+ | | ||
+ | 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, | ||
+ | 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, | ||
+ | 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 | ||
+ | | ||
+ | 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, | ||
+ | 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. | ||
- | Others have more critical limitations: | + | |
+ | The protocol RFC 3161 is a standard for TSA (Trusted Timestamping Authority) services, | ||
+ | whose usage is described in the following section. | ||
+ | |||
+ | There is also a possibility to do it with the block chain, to avoid central authority. | ||
+ | |||
+ | There are a few freely available services for individuals, | ||
+ | Some are certified by some administration (for instance [this list](https:// | ||
+ | for the french ANSSI, or the european eIDAS regulation), | ||
+ | some have a specialized TSA certificate that can be chained to a trusted root certificate, | ||
+ | and some are just an independent party, but not authorities. They also provide different accuracies, and sometimes | ||
+ | no accuracy information at all (in this case it is not clear if a reasonable default value can be opposed), | ||
+ | and support different types of cryptographically secure hashes | ||
+ | (the best one being SHA512, with SHA256 ok as well; did not find any supporting SHA3). | ||
+ | |||
+ | Free services (as of 2022): | ||
+ | * Certified in France or Europe: | ||
+ | ** N/A | ||
+ | * 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: | ||
+ | ** DigiCert ([[https:// | ||
+ | RFC 3161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate | ||
+ | ** EnTrust ([[http:// | ||
+ | RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate | ||
+ | ** Comodo / Sectigo / USERTrust ([[http:// | ||
+ | RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate (failing to verify for unknown reasons though) | ||
+ | ** Apple ([[http:// | ||
+ | RFC 3161 from TSQ, sha512, accuracy 1s | ||
+ | ** Symantec / VeriSign ([[http:// | ||
+ | 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: | ||
+ | ** FreeTSA ([[https:// | ||
+ | RFC 3161 from TSQ, sha512, no accuracy, self-signed certificate | ||
+ | ** ItConsult ([[http:// | ||
+ | PGP signature with index by email | ||
+ | |||
+ | Limited services: | ||
+ | * TrueTimestamp ([[http:// | ||
+ | RFC 3161 by form, and by URL 5/day, sha256, not tested | ||
+ | * DigiStamp ([[https:// | ||
+ | account, 25/year free | ||
+ | |||
+ | Services With free trial duration: | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | Others have more critical limitations | ||
* [[http:// | * [[http:// | ||
- | * [[http:// | ||
* [[http:// | * [[http:// | ||
+ | * [[https:// | ||
* [[http:// | * [[http:// | ||
+ | * [[https:// | ||
You can also use a software client to use the RFC 3161 protocol, with a server providing the service: | You can also use a software client to use the RFC 3161 protocol, with a server providing the service: | ||
Line 35: | Line 138: | ||
* [[http:// | * [[http:// | ||
* [[http:// | * [[http:// | ||
- | |||
- | ==== File size problem ==== | ||
- | One problem I encountered with all providers I tried is that they limit the file size (at least for free services), around 1 MB. | ||
- | So what I do is that I sign the large file with my own PGP key, then I officially | + | Lists of services: |
+ | |||
+ | Sources: | ||
+ | * [[https:// | ||
+ | * [[http:// | ||
+ | * List of rfc3161 servers: [[https:// | ||
+ | * Certified services by the french administration ANSSI: [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | ==== RFC 3161 ==== | ||
+ | |||
+ | === Get timestamp === | ||
+ | |||
+ | With TSR request | ||
+ | openssl ts -query -data < | ||
+ | curl -H " | ||
+ | </ | ||
+ | |||
+ | Directly | ||
+ | hash=($(sha512sum < | ||
+ | curl -H " | ||
+ | </ | ||
+ | |||
+ | === Inspect files === | ||
+ | |||
+ | TSQ request:< | ||
+ | openssl ts -query -in < | ||
+ | </ | ||
+ | |||
+ | TSR request:< | ||
+ | openssl ts -reply -in < | ||
+ | </ | ||
+ | |||
+ | === Verify timestamp === | ||
+ | |||
+ | From the original file:< | ||
+ | openssl ts -verify -in < | ||
+ | </ | ||
+ | |||
+ | From the TSQ request | ||
+ | openssl ts -verify -in < | ||
+ | </ | ||
+ | |||
+ | From the digest:< | ||
+ | openssl ts -verify -in < | ||
+ | </ | ||
+ | |||
+ | Service certificates can be extracted from the TSR response file if they were embedded:< | ||
+ | openssl ts -reply -in < | ||
+ | </ | ||
+ | |||
+ | And decoded with:< | ||
+ | openssl x509 -in globalsign-root-ca.pem -text -noout | ||
+ | </ | ||
+ | |||
+ | These extract should however only be used with the -untrusted argument, and trusted certificates | ||
+ | should be used for the -CAfile argument, downloaded from the service | ||
+ | .crt files can be converted | ||
+ | openssl x509 -inform DER -outform PEM -in <file>.crt -out < | ||
+ | </ | ||
+ |