Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
software:pgp [2011/02/27 19:48] cyril |
software:pgp [2022/04/08 00:22] cyril fix alignment issues |
||
---|---|---|---|
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, while ensuring confidentiality of your data. |
- | * [[http://www.itconsult.co.uk/stamper.htm]]: probably | + | * 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, | ||
+ | * 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 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, | ||
+ | * note: when serial timestamping, | ||
+ | * 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 36: | Line 102: | ||
* [[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), | + | 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 with hash (does not work with all services):< | ||
+ | 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 file:< | ||
+ | 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 website. | ||
+ | .crt files can be converted to .pem files with the following command:< | ||
+ | openssl x509 -inform DER -outform PEM -in < | ||
+ | </ | ||
- | So what I do is that I sign the large file with my own PGP key, then I officially timestamp my signature. My PGP key doesn' |