Feedback on TimestampIt! carried over from RFC3161.txt

gistfile1.txt

This gist is carrying over a discussion from a different gist: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710?permalink_comment_id=5147220#gistcomment-5147220

This gist was started so as not to disrupt the original purpose of that gist which is compiling a list of working RFC3161 TSA servers (with thanks to @Manouchehri for compiling and maintaining that gist).

@JohnPlanetary gave some nice feedback in this comment: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710?permalink_comment_id=5151554#gistcomment-5151554

I am replicating the comment here:

> timestampit without RFC 3161 and RFC 5816 support doesn't make a lot of sense here in these topic. In fact I would argue that since RFC 3161 and RFC 5816 are the standards and are supported by so many programs that is still relevant, the magic part should be the part to be able to verify in the future that the file was really timestamped 23 years ago... I've been testing TSA's for a long time and basically is almost impossible once the TSA expires to proof anything since it will start to give errors... since CRL and or OCSP usually stop working and stops being possible to verify anything.
> 
> timestampit could have say a different key for every year using RSA 8192 bit SHA512 key to timestamp using RFC 3161 and RFC 5816, and say 150 years of year key lifetime, the main Root with say 500 years lifetime, RSA 16384 bit SHA512. and every year a new key with 150 years of key lifetime.
> 
> > TimeStampit Root Key (RSA 16384 bit SHA512) [From: 2024-08-12 - Until: 2524-08-12]
> > > TimeStampit 2024 Key (RSA 8192 bit SHA512) [From: 2024-08-13 -> Until: 2174-12-31] [signs between 2024-08-13 00:00:00 until 2024-12-31 23:59:59]
> > > TimeStampit 2025 Key (RSA 8192 bit SHA512) [From: 2025-01-01 -> Until: 2175-12-31] [signs between 2025-01-01 00:00:00 until 2025-12-31 23:59:59]
> > > TimeStampit 2026 Key (RSA 8192 bit SHA512) [From: 2026-01-01 -> Until: 2176-12-31] [signs between 2026-01-01 00:00:00 until 2026-12-31 23:59:59]
> > > TimeStampit 2026 Key (RSA 8192 bit SHA512) [From: 2026-01-01 -> Until: 2176-12-31] [signs between 2026-01-01 00:00:00 until 2026-12-31 23:59:59]
> 
> If the CRL('s) can be included within the signature (still doesn't happen in most programs) then theoretically the timestamp could be believed until its expiration date... as long the company itself doesn't have any troubles coming up like the private key being stolen or cracked.
> 
> RSA 16834 bit key with SHA512 should be fine for the Root, but usually can't be used for the final signing key because it will give too many errors at least in my tests it would fail on most signing programs because would take too many memory/ space reserved for the signature.
> 
> NIST P-521 could theoretically be used but the problem is that in reality the security level of it should be lower than even RSA 3072 bit key at least if quantum computing is used to try to find the private key.
> 
> Ok... but what if TimeStampit doesn't want to support RFC 3161 and RFC 5816? In what it would be different from other services online like: https://truetimestamp.org , https://opentimestamps.org , https://tzstamp.io , https://timestamp.decred.org and https://notbot.me ? What happens if TimeStampit closes in 6 years time, how would people be able to prove to others that timestamp is real? Some of the services above include some sort of bitcoin or other coin integration to make it more easy to proof in the future (as long those continue to exist)... in some cases judges may not accept them since it wouldn't be easy to verify by themselves and they may or may not believe experts, if it seems magic mumbojumbo... and to my knowledge there is no standard log database for timestamp similar to Certificate Transparency (where people can search for the certificate from multiple sources using for example: https://crt.sh ) where I think the certificate companies need to publish to more than one log database (at least one being from others not related to that company) in order for others to trust it and be able to verify things after the fact.

This is good feedback @JohnPlanetary and thanks for trying out timestampit.com.

Since time stamping should be something that can be confirmed in a long time, and because you really want to just use standard algorithms, maybe then use SHA-512 or SHA3-512, and just not use SHA256 at all, and in elliptic curve use Ed448 (that is main stream since can be used in TLS 1.3 connections) and provides a litter better security level then Ed25519.

TimestampIt! does support SHA3-512 and a bunch of other hash algos, but only through the API. The reason the website form uses SHA-256 or SHA-512 is that is supported natively in all modern browsers. Once SHA3 gets supported I will definitely switch the web form to that.

I will also look into using ED448.

I would suggest to make your design to be picked up, to have working clients for the Operating Systems

I understand where this feedback is coming from. But I do not fully agree. Thick clients are just another point of trust that could be attacked. This is why my example clients are just thin open source scripts. And the design of my Trusted Timestamps are plain text and very easy to parse.

I have been thinking about some of your earlier feedback around making a global database of timestamps, whether it is a blockchain or something else. I think this is really interesting and is something I hope to work on at some point.

Some random thoughts on this:

Instead of a blockchain, a distributed hash table might be an even better data structure since it should allow for faster verification of timestamps.

Having some kind of token based market where users making timestamps pay a token to node operators who maintain the distributed hash table (or blockchain) could incentivize keeping the network operational.

What about simply putting timestamps into Twitter (X) as a place for permanence? Or Nostr?

For now I'll keep operating timestampit and seeking more feedback. I am going to publish my GitHub Action soon to allow timestamping code, hopefully that gets a few more eyes on this project.

If you ever want to talk more about timestamps or see other intersting developments in this space I'd love to hear about it!

Using social media for hash deposit has already been done, for example by originstamp, and if I record it correctly their account had troubles because Twitter identify the use of the account as abusive since they were probably using some bot to publish the information. I think they had to stop use Twitter for that (hash publishment), and any other social media will be subject to the same problem since any of them can decide at anytime they don't like that use and ban the person... of course one can have its own server with some social media application running but that would just be resource intensive, it would open a world of security troubles to take care... it would make more sense to just publish some log file of everything that could be searched on a webpage interface, and maybe even have for example some year/ month/ day folder structure where the main log would be cut to that specific day to make public indexing by third parties (like: https://archive.org/web/ and for example: https://archive.ph and common search engines) easier. And so html pages could be both PGP signed and the html file itself could be signed with for example some PKI digital certificate (.p7b format for example) using for example RSA 16384 bit SHA512 certificate for the owner and some timestamp. And include in the html file itself the OpenPGP key used and the PKI certificates used and the URL to find them on the web site (also available in html to allow easily index of it by third parties archievement web sites, to allow users and expert easier verification even if the service vanishes in the future).

"Having some kind of token based market where users making timestamps pay a token to node operators who maintain the distributed hash table (or blockchain) could incentivize keeping the network operational."

Yes, these is being done by some timestamp operations using bitcoin and other coin based systems, so it shouldn't be impossible. But if it is some distributed hash table or blockchain for just timestamp purpose (to make it faster) it will probably be harder to have a lot of people supporting the network, unless it becomes a standard in the industry and people can make real money with it. Specially the "distributed hash table" would be harder because with more and more people on the network the payment would go down and down to possibly near absolute nothing... at least I'm not seeing the possibility of charging even one cent of dollar to pay 10 000 database holders... each timestamp would cost 100 dollars, eh eh, not very realistic... I know no one that would accept such high prices. Lets not forget that not enough people will maintain a database network if they can't make money out of it somehow... of course those providing the services would be incentivise to do it, and maybe also some courts and similar, but not everyone so the success would be difficult (success in the sense of having a lot of databases around from multiple sources).