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.

Thanks for your thoughts @JohnPlanetary

Many of these thoughts are inline with how TimestampIt! was designed. Some are not, I’ll try to respond concisely to those points. I’m not clear on the extent you have looked at the TimestampIt! design? Much of this feedback is pretty general, though still valuable.

To be truly different of all other [timestamps] already available it should be possible to both verify the data online and offline.

Truly offline verification is impossible as far as I know, short of having some trusted hardware with immutable root certificates/keys built in. I do not believe anyone has Trusted Timestamps that can have a 100% correct verification that is truly offline. However, you can get close enough to call it good I think. RFC3161 timestamps can verify offline using the TSA certs and your operating systems preloaded root certificates, and that is a nice design that requires industry wide coordination. BUT, a malicious program could potentially tamper with the preloaded certs, or could alter the verification program to use bad certs. I am sure there is other attack vectors.

The timestamps from TimestampIt! are verifiable without having an internet connection. All you need is a copy of the keychain (https://github.com/timestampit/keychain/blob/main/keychain.json). You can use our example verification scripts (https://github.com/timestampit/example_clients/) or write your own quite easily using any ED25519 signature verification library/app you want. The commits in the keychain repo are signed, and I am scheming some additional mechanisms for verifying the keys and ensuring they are authentic. Will it prevent a truly determined attacker, I suppose not. But using fresh keys on every verification gathered from a trusted source (like timezstampit itself, or the GitHub backup) largely mitigates this. Is it safe for 100s of years? I don’t know that anything in this space is. Quantum computers are coming and may render much of our cryptography broken.

The applications should all, from the get go, be open to third parties to be able to use it,…

TimestampIt! Is open to third parties to do what they want with it, though our terms of service permit only legal usage. But since the data works off hashes, we don’t really have any insight into what the source data actually is. If someone is timestamping illegal materials we are not going to know. And because TimestampIt! is just an API, you can use and standard program to create timestamps with it, like curl. The create/verify functionality on our website is really just for demonstration purposes.

The design of our Trusted Timestamps is also vendor agnostic. I would be honored if another TSA replicated or improved the design.

At some point, after getting more users and more experts to review the design and help improve the service, we might write an RFC and really standardize it. But for now it’s an experimental service and we are looking for expert reviewers to find the holes in the design.

I think your points about having a log database are interesting and somewhat inline with putting timestamps on a blockchain. Blockchain timestamps are pretty interesting but I have not seen a standardized design that does it well, especially when it comes to verification. It is something I have been thinking about. One challenge though: What kind of usage is important enough to justify the cost of using a mainstream blockchain to record the timestamps? AFAIK, no one really pays for Trusted Timestamps by themselves, though some users do pay for programs that make use of them.

Happy to take any more feedback that is specific to the design of TimestampIt! Trusted Timestamps 💚

As I told, I'm just a user, I'm not a coder.

These is important, because in order to test the service you would need to have a full working web site (signup is not working) and a full working application (at least for Microsoft Windows).

Well, offline verification is already a standard in PDF's: ETSI EN 319 142-1 PAdES B-LTA, and in EU the chain of trust can be obtain here: https://eidas.ec.europa.eu/efda/tl-browser/ So I guess we already have truly offline verification in place right now, as long as the application also keeps the timestamp CRL/ OCSP values also stored and that is something that I'm yet to see any program do... I can only get that by forcing it in Adobe, and even that won't work many times for unknown reasons to me.

If malware is present then nothing will be truly safe.

I understand the use of ED25519, but I would recommend against it, since even the most common available elliptic curve for use NIST P-521 is less secure then RSA 3072 bit... even if it doesn't come with some backdoor... at least when the technology allows for cracking current RSA and elliptic curves, the elliptic curves should be the firsts to be cracked successfully.

If you must use elliptic curves I would suggest a bigger one like "anders_1032_1" (1033 bit) available here: https://intern.fh-wedel.de/~an/crypto/accessories/domains_anders.html (that one is explicitly available for commercial use) still not the ideal, since is probably way small then what is really needed but at least when normal elliptic curves are cracked these one may still keep secure for a while (depending on the way they are able to revert from the public key to the private one) since is more then double the maximum size usually available and even then the more common use is those ED25519 and NIST P-256 elliptic curves that are way way smaller!
Of course you can do your own elliptic curve, and that is exactly what experts recommend, for every application/ protocol/ standard to have its own elliptic curves (if they use that) to make attacker life harder. The standards only benefit attackers both state sponsor and private ones. The experts only warning people doing their own curves to be careful to test them for some common mistakes that may render the elliptic curves insecure.

You did refer that you don't know anything that will be safe in 100's of years, and really the only way that could be possible would be to be in paper with all those things applied to make the forgery difficult and have that in some sort of permanent archive place that is keep by the public taxes. Other than that putting the information into the M-Disk's or similar long life physical medium, I don't see how that information wouldn't be lost. And who knows if in 300 years there will be any way to read M-Disk's even if there isn't some World Wide War.

The forgery of data, I think that there is already a solution that is used currently in the real world, basically as long who ever holds the data can be sure no one has change it, they can simply apply new signature algorithms on top of the old ones such that they can be sure that the information is valid in the future and hasn't been tampered. If they simply stamp a new newer timestamp with the current time at that time, or have some way to read the original timestamp time and transport it to the new timestamp information as a sort of "original timestamp preservation" I'm not sure... these makes sense, but I think they usually will only add a new timestamp to be sure no one changed the information and when they need to verify the data they will check the old original probably no longer secure timestamp... so the "transport" of the old data from the previous timestamp to the new one should/ must (!?) always have a field that informs the original document secure timestamp data, that way would be theoretically possible to keep the records securely updated & verifiable, even if old algorithms aren't secure since centuries ago (at that time).

"If someone is timestamping illegal materials we are not going to know.", I think you didn't understand what I told, they aren't sending hashes of illegal stuff that they hashed, they are using the "space" that the hash uses in the database to send their personalized encoded data such that they can store images in the databases even if they need to distribute over several "hashes" to then be able to retrieve that information from the databases, being the idea that as long that database is available and they have access to it, they can retrieve the information for example knowing the exact timestamps where that is stored to get the "hashes" and download them to revert into the images themselves. I know, why do that? So that they can always get the images back again later even if someone or something deletes them... they can find a way to neutralize whatever is doing that and then reconstruct the images from the database since that information can be made less obviously about what it is. At least is what I think can be the reason to store illegal stuff using the hash space in the databases.

"What kind of usage is important enough to justify the cost of using a mainstream blockchain to record the timestamps?" that is the point of the suggestion, not using some normal blockchain (that have transaction fees), but create one from the scratch just for these purpose that can be used by everyone and that can be replicated/ keeped locally by anyone who wants to check at anytime the information including offline... that is the kind of thing that courts usually like the most, something that can be easily obtain and checked for example by the judges themselves. Who would want to use such a thing? Notaries, Courts, Governments, and other legal industry that wants to keep timestamps in a permanent record.
But who wants that to be permanent? For example some government, company, organization, newspapers, that wants to know exactly when some document or transaction did take place, because depending in the laws or whatever they may be able to defend themselves or prove something in a way that everyone believes at least in the timestamp (since they can verify in the blockchain that it is really there).

"no one really pays for Trusted Timestamps by themselves", people do pay timestamps by themselves, there is no shortage of services selling that either individually or in a bigger "package". But mostly governments, private notaries, banks, lawyer companies, and probably many others that need to keep records and proof they didn't tampered them.
These is the reason I think the main focus of these would probably be those sorts of clients, if you want to charge for it and really make money.
Some solutions already announce integration with blockchain technology... but I'm yet to see one that is truly open and usable by anyone, and isn't just using some coin blockchain or some proprietary blockchain that one needs to pay to play.
Where would the money be at? The applications, hardware and maintenance contracts for those bigger clients. What about the "normal" people? Either you don't care about them at all in your solutions, or you can for example provide paid applications also for them for the timestamp, and for example free database online and offline viewer (and download of the database) for anyone to check the information. The application may allow access to anyone that supports the technology, and maybe allow a number of timestamps in a certain provider included in the application purchase.

"Happy to take any more feedback that is specific to the design of TimestampIt! Trusted Timestamps", to be fair I can't provide feedback on the specific design of TimestampIt! Trusted Timestamps, because of what I already wrote above "These is important, because in order to test the service you would need to have a full working web site (signup is not working) and a full working application (at least for Microsoft Windows).", and also because your service doesn't seem to have available anywhere some explanation that a person like me could understand, a good example of technology explanation is for example here: https://www.grc.com/sqrl/sqrl.htm where the "Secure Quick Reliable Login" technology is explain in a technical way I can mostly understand.

These is important, because in order to test the service you would need to have a full working web site (signup is not working) and a full working application (at least for Microsoft Windows).

I did have a bug that prevented signup from working, but it is now fixed. Signup and all other features on the website should now be working, including basic timestamp creation and verification (please let me know if you see otherwise 🙏). You can use public with password publicpublic to login and try it out too without signing up.

But it sounds like you understand the larger parts of the design pretty well already, and I do appreciate your expertise on the rest of the feedback, you definitely know more about this stuff than I do! I'll have to go through it more in depth.

As the design stands I am not using the hash algos you recommend, I do plan to support more hash algos soon though. My original thoughts on the design are I wanted to build a really nice modern API, and have other companies/entities build out the clients. So this initial launch I designed it to work with standard open source tools that are widely distributed.

I do take the point about people using hashes to do storage for actual files. The TimestampIt! servers only stores timestamps for 24 hours and then deletes them. Users are currently on their own for storing the trusted timestamps. I wouldn't want to store longer unless there is a paying customer which at this moment seems like a pretty remote possibility.

And I do intend to improve the documentation too and hopefully get something that makes sense to people who have never heard of trusted timestamps at all.

One thing I wonder about and perhaps you have some insight: Is there a good way to bring identity into Trusted Timestamps? Is there a good design that would record who created the trusted timestamps? I am thinking about people creating videos and wanting to mark them as authentic so that people could be assured they are not deep fakes. I could add email address into the data in the Trusted Timestamp, and only allowed recently confirmed email addresses to to create these identified trusted timestamps, but that feels pretty flimsy.

Thanks again for taking the time to engage with my admittedly novice project.

Yes, I created my account and now works properly.

I've tried, and it probably should also include a verification page to send the key, signature file and the file that was timestamp to check if all 3 are matching and are what they should and also present the information (time, hash, etc.) if everything is ok.

I've test sending just the file and it did work fine, it detected that the file was timestamped.

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.

While I'm not an expert at the matter, I have a deep interest in these area because as I wrote before I like to timestamp stuff and definitely there is almost nothing that resisted the test of time until now, if I had to trust some online system to be available in the future I would probably go, currently, with https://truetimestamp.org since that has been around for years. Not saying that thing is perfect, just that has been working fine for years.

I would suggest to make your design to be picked up, to have working clients for the Operating Systems, to improve the chance people will really use it. They may be simple, but fully working, and you can encourage people to develop their own applications if they don't like and make it explicitly that your applications are aimed at proofing that everything works as advertised.

Yes, paying for infra-structure only make sense if you can get some clients to pay for it. But probably no one is going to pay if you don't have a clear good working system that makes sense and can start to be used immediately.

Usually timestamps are specifically and on purpose left without Identity associated to them so that it is as much usable everywhere as possible. RFC 3161 and RFC 5816 are a good example of that, they are used to sign PDF documents, but also executable, and anything else with external timestamps. Privacy is also a selling point to many since they can anonymously timestamp files. When people want to assign some identification they will either do that in the document/ image/ file himself, or sign with a digital certificate (usually using RSA or ECC algorithms).
Good example of program that can just timestamp, or just sign with a digital certificate, or do both, is: XolidoSign ( https://en.xolido.com/lang/xolidosign/xolidosigndesktop/ ). It uses the RFC 3161 and RFC 5816 for the time stamping, in that way is somehow limited since they don't include some online blockchain that can confirm the time stamps when they expire. But you can see that despite they provide that program for free for years, they have a lot of paid services for the companies, governments and who ever else wants them. So it is possible to provide free stuff for everyone and still make a lot of money.

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).