PGP and GPG
I will talk on this page of everything related to security and authentication on the Internet.
Personal use
PGP and GPG are two compatible asymmetric encryption and signing software. Their features are:
encrypting emails or files: you use the public key of the receiver to encrypt the message so that only the receiver can decrypt it (using his associated private key).
gpg --recipient <user-id> --encrypt <file>
gpg --decrypt <file>.gpg
signing emails or files: you use your own private key to sign the message so that anyone can verify with you public key that you are the author of the message, and that the message was not altered.
gpg --detach-sign --armor <file>
gpg --verify <file>.asc
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 Timestamping
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 existed at this time, and has not been altered since.
Remarks:
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 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 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, 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).
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.
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, but they don't all have the same level of trust.
Some are certified by some administration (for instance [this list](https://www.ssi.gouv.fr/administration/qualifications/prestataires-de-services-de-confiance-qualifies/prestataires-de-services-de-certification-e)
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:
TSA with accuracy and chainable to ubiquously trusted certificate (all trust stores):
GlobalSign (
server):
RFC 3161 from TSQ, sha512, accuracy 1s
Certum (
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:
DigiCert (
infos,
server):
RFC 3161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate
EnTrust (
server):
RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate
Comodo / Sectigo / USERTrust (
server):
RFC 6161 from TSQ, sha512, no accuracy, but ubiquously trusted certificate (failing to verify for unknown reasons though)
Apple (
server):
RFC 3161 from TSQ, sha512, accuracy 1s
Symantec / VeriSign (
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:
FreeTSA (
infos,
server):
RFC 3161 from TSQ, sha512, no accuracy, self-signed certificate
ItConsult (
infos): PGP signature with index by email
Limited services:
TrueTimestamp (
infos):
RFC 3161 by form, and by
URL 5/day, sha256, not tested
DigiStamp (
infos): account, 25/year free
Services With free trial duration:
Others have more critical limitations or expansive:
-
Polito.it: untested, only works with a software client.
-
-
-
You can also use a software client to use the RFC 3161 protocol, with a server providing the service:
Lists of services:
Sources:
RFC 3161
Get timestamp
With TSR request file:
openssl ts -query -data <file> -sha512 -cert -out <file>.tsq
curl -H "Content-Type: application/timestamp-query" --data-binary "@<file>.tsq" <service-url> > <file>.tsq.tsr
Directly with hash (does not work with all services):
hash=($(sha512sum <file>))
curl -H "Content-Type: application/timestamp-query" "<service-url>/?sha512=$hash" --output <file>.tsr
Inspect files
TSQ request:
openssl ts -query -in <file>.tsq -text
TSR request:
openssl ts -reply -in <file>.tsr -text
Verify timestamp
From the original file:
openssl ts -verify -in <file>.tsr -data <file> -CAfile cacert.pem -untrusted tsa.crt
From the TSQ request file:
openssl ts -verify -in <file>.tsr -queryfile <file>.tsq -CAfile cacert.pem -untrusted tsa.crt
From the digest:
openssl ts -verify -in <file>.tsr -digest <hash> -CAfile cacert.pem -untrusted tsa.crt
Service certificates can be extracted from the TSR response file if they were embedded:
openssl ts -reply -in <file>.tsr -token_out | openssl pkcs7 -inform der -print_certs
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 <file>.crt -out <file>.pem