Show HN: Seal – Verifiable timestamp for your private ideas | Hacker News Reader

Show HN: Seal – Verifiable timestamp for your private ideas

docs.planet.ink

113 pointslosfair65 comments

As another commenter noted, there's a general internet standard defined already for cryptographically timestamping and signing digital artifacts, like JARs, PDFs, dotNet assemblies, and many others.

https://datatracker.ietf.org/doc/html/rfc3161

Many large certificate issuing orgs run timestamping authority servers. Tools like Java jarsigner, Adobe Acrobat, and many other tools are designed to work with them. Search for "rfc3161".

I’d like to add that one should be aware that such timestamps are only valid until the TSA certificate expires (or is revoked). To prolong the validity, you need to add another timestamp on top, using a newer certificate, to prove that the first timestamp was created before its certificate expired/was revoked. This is a recursive process. If the TSA renews its certificate every N years, it makes sense to accordingly re-timestamp every N years to keep the original timestamp valid. To guard against the case of an untimely revocation, you may want to timestamp with multiple TSAs each time.

That's not really the case -- at least on Windows, timestamp signatures persist past the timestamping certificate's validity, it's their whole point. I just looked for something signed on my PC to find that Office 2019 installations were signed & timestamped on 2019-12-01 by Microsoft with both certs (code-signing and timestamping) valid 2019-2020. The signature & timestamp remain valid.

It may be the case that Windows behaves that way, but it means that if the signature and timestamp were fraudulently created after the fact, enabled by a key compromise or an algorithm compromise, Windows would incorrectly treat them as valid although they aren’t.

> if the signature and timestamp were fraudulently created

This is enough, independent of whether or not it happened after any of the certificates involved have expired. I don't think most consider total "key compromise" (of the 3rd party timestamping cert + the code signing cert) part of the threat model... but if there was an issue either could be revoked at a specific point in time. (Mentioning algorithm compromise takes away from your argument, when that happens entire segments of PKI get tossed.)

https://knowledge.digicert.com/generalinformation/INFO1119.h...

A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.

That's why only about 10 timestamping authorities exist (at least in a trust sense) on Windows, and they're held to a much higher security standard compared to every other signing operation. Could just be an independent HSM with its own atomic clock to prevent such attacks.

Otherwise there's no viable way to actually use timestamping, or your archived timestamped files would just randomly become untrustworthy. Keeping the signature valid using a timestamp (and giving the timestamp special standing) means you can still trust something like a Windows XP installer 20 years later without needing to save a hash ahead of time (and without worrying the hash you saved elsewhere was maliciously changed to fit the changed file).

> I’d like to add that one should be aware that such timestamps are only valid until the TSA certificate expires (or is revoked).

This is simply not true.

More precisely, it depends on the definition of "valid", but conventionally the death of a notary doesn't invalidate their notarizations.

The issue is that you need to apply a time to the certificate path validation (RFC 5280). If you apply the current time after certificate expiration, the validation will fail. But if you have no proof of when the signature was actually created, then using an earlier time incurs the risk of judging a fraudulent signature as being valid. This can be due to key compromise, for example, or due to algorithm compromise. In the context of signatures, timestamps serve exactly the purpose of providing the proof that the signature was created before a possible compromise. If however one doesn’t apply the same logic to the timestamp signature itself, the whole exercise becomes moot.

Of course, after a risk assessment you may still decide to treat an expired signature (timestamp) as valid in a concrete case, but it would be a questionable practice to do so in general for an automated validation procedure. It would effectively mean that you ignore the expiration date of certificates and treat them as being valid indefinitely. Those expiry dates exist precisely to contain the risk of fraudulent key use. Accepting signatures after certificate expiration without having proof of when the signatures were created completely undermines that mechanism.

An additional issue is that CAs are not required to maintain and publish revocation information (via CRL/OCSP) for expired certificates, which means that in general you lose the ability to even check the certificate for revocation. This is why AdES formats provide the ability to store revocation information with the signature (and also timestamps). Of course, to make use of revocation information you have to validate the CRL/OCSP signatures, which in the long run again requires adding timestamps covering those.

> it would be a questionable practice to do so in general for an automated validation procedure

Or, as parent mentioned ("conventionally"): standard practice.

Yes, if you have nothing in place to update and check CRLs and transition away from SHA1, you're gonna have a bad time. Is that the clarification you're trying to make? It's not like expiration vs. revocation hasn't been considered:

https://social.technet.microsoft.com/Forums/ie/en-US/405be5d...

certificates remain in the CRL indefinitely - Code Signing and Kernel Code Signing

I love these sorts of hacks. In fact I did something similar with a project called rget[1] two thoughts:

1. My project got politely asked to not use the ct log and lets encrypt infra this way. Since you are only doing it every 12 hours you might be ok.

2. Sigstore[2] seems like it might be a good match and their infra is designed for lots of small fast one off sigs.

[1]: https://merklecounty.substack.com/p/rget-a-secure-download-u...

[2]: https://sigstore.dev

Alternatively, every large CA maintains a public TSA server (time-stamping authority), because it's an integral part of the code signing framework. These are meant for high loads, so they can be used to sign each document individually.

https://en.wikipedia.org/wiki/Trusted_timestamping#Trusted_(...

I previously came across TSA but it seems that they don't log to a public ledger like the CT log?

Why would they log into a public ledger? That's not how the PKI works.

PKI works nicely under its presumptions, but a public ledger (like CT where TLS certificates are logged to) is a useful enhancement to it. That way you can actually verify things instead of just trusting the CA.

There's also https://opentimestamps.org/ for timestamping into the bitcoin blockchain using a 'calendar aggregation' concept. Clients get back a merkle tree of hashes that can be used to show inclusion in a published hash on the blockchain.

I've been using opentimestamps/ots for a few years now. It can be used to show a specific version of a file existed as early as the proof date. Unfortunately the only other value seems to be showing that if you had doctored a file then that happened at least as early as the timestamp and not later.

What can you achieve with such a proof?

Proof that something was there at some time in the past + proof that the contents haven't been tampered with.

It's only proof that the contents (should it match the original hash) haven't been tampered with after the timestamping.

backlink to a related recent discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022...

A bunch of comments below indicated that this is technically an abuse of the CT logs. Feel free to use Sigstore instead for this, it's basically the same architecture as CT logs except we officially support and endorse this use case.

https://www.sigstore.dev/

Abusing CT log is unethical.

For practical purposes DKIM signatures in emails would do the trick.

Write an email to yourself, or to someone you trust, its DKIM will include the timestamp and it can be verified publicly.

The DKIM idea will not work: some email servers intentionally publish their expired DKIM keys to avoid people leaking mails (https://blog.cryptographyengineering.com/2020/11/16/ok-googl...)

Google does not. In many ways, non-repudiation property of emails is a boon. We do not hear much about it, but I bet that many thousands of legal disputes are settled once people realize that their emails can be verified via DKIM signatures.

The fact that it allows to verify the authenticity of leaked emails is only a small and not necessarily negative side-effect.

A cleaner, simper solution to that is for email clients to delete the DKIM info immediately upon receipt.

I don't see why it matters. Sounds like they aren't going to be registering many domains. Looks like they register something like 4 domains a day, which is completely insignificant.

In Poland you can use "podpis zaufany" to sign a file, which also records the date of signing. The only thing you need is a bank account which was verified using your physical ID. The best UX, I think, is with PDF files - others are encapsulated in an XML Base64 container. Everyone can verify a signature with no account necessary.

A polish bank account I suppose?

I'm not sure what the value proposition is here. Is the idea that you want to use this later to tell others you had the idea first, or to protect your IP?

If so, I could definitely see people noting every conceivable idea they can imagine to claim rights later

... Otherwise, is it because I don't trust my past self to be accurate?

Or to prove to 3rd parties you absolutely did what you said you did at a time? In which case it's not private.

In some patent law jurisdictions, date of invention trumps date of filing if you can show evidence.

Hence my comment on people spamming ideas to front-run it.

Other than that, I can't really see a need for this that is for private use.

I want to show everyone how smart I am about predicting current events, or prove that I knew some secret event happened, without my prediction causing interference.

You can just publish encrypted text as a GitHub gist (or use any other large public site where you can't modify the timestamps), and then release the decryption keys later.

Or only publish a hash that used some collision-resistant function (future proof), and then publish the text that matches the hash later. For this, you can just tweet it, or write it into a HN comment.

$2a$12$0qd0ztFAO5XAjQ.HRDMxjeS3n6tsemeHfWfWO0MIBR0mwFfmyp2RO

Actually there is no where left in the world where this is the case. USA was the last country to use first to invent and we switched away in the mid 2000s

Interestingly enough this was the last time I was being taught basic patent law at University!

There were also a lot of carve outs that got things grandfathered into the first to invent rules. But at this point it’s pretty much completely gone.

One other thing you can do for resilience, is periodically (say every 6 months or so) take out a full page ad in The NY Times with the hashes.

These newspapers tend to be archived all over the world by multiple people, and are another way to provide proof that something was published by a certain date.

For anyone who’s interested in a quick and dirty way to do it, I just post the sha256 to Twitter/some public forum and reveal when I feel like it

Seems like an interesting problem, but I have zero background knowledge. Could you share who would use this and why?

If you want to prove you had an idea first, or something like that.

Outside of patents, which is already a thing, with a very large legal framework around it. Why is that important?

Pride I guess? I'm sure there are other uses. This idea has been done many times before (e.g. with blockchains).

Under Obama, the America invents acts switched patent IP ownership to first to file.

Inventing something first no longer matters in patent law.

This has been done for a while. Two links:

- https://en.wikipedia.org/wiki/Linked_timestamping

- https://www.vice.com/en/article/j5nzx4/what-was-the-first-bl...

The company in the second link: http://www.surety.com/

As far as I understand there's also Zeitgitter[1], to provide similar proof.

[1] https://github.com/zeitgitter/zeitgitterd

Zeitgitter goes even further: The goal is to create a web of distributed timestampers, holding each other accountable. A blockchain without the need for wasting energy or money. https://netfuture.ch/2022/02/git-pgp-blockchain-comparison/

The only thing I don't get, and forgive me if it's a dumb question, what's the difference with say sending yourself an email/making a github repo/entry/any timestamped note?

They can be faked. This, supposedly, cannot.

This could be implemented via blockchain too , where in you can prove that you had posted the idea before a certain block was mined. Timestamping blocks can be done via schilling coin based oracle.

https://opentimestamps.org/ use the same idea (using a merkle tree to make it cheap per document) with the bitcoin.

Here is a rough one I wrote that uses Optimism (Ethereum Layer2) https://sonotoki.org/

I think it's already a thing. See proof of existence.

In other news: employees of letsencrypt have unexpected windfall due to their massive library of prior art, which they are apparently willing to nix after suitable payment has been received.

I don't understand, what do you mean?

This is a good hack, even with some very light abuse (once per 12 hours) of CT logs.

I don't see the need to build new tech though. It should be trivial to build a CRUD layer over git repo (which uses a merkle tree DAG) - and you get public logs to boot, including simple hosting and wide tooling. Immutable commits maintained in a public tree. This could also be combined with the above hack (using commit id).

I'm confused how a git repo would help. You can easily write commits in the past.

e.g. git commit --date="10 day ago" -m "Your commit message"

Only to the HEAD. If you publish the repo somewhere that does not do garbage collection, this can work.

Why does the fact that you can only do that to the HEAD matter? I can still fake any time in the past.

Also, I'm not aware of any public host that does not do garbage collection. But even if that were the case, you still need to trust whatever the repository host is.

If you have a third party sign your git commits, you no longer can no longer modify the commit later undetectedly. And if someone puts their log of signatures into another git repository, you can create an entire web of timestamped trust. https://netfuture.ch/2022/02/git-pgp-blockchain-comparison/

This is true. Although now this is starting to pretty closely approach what the OP is doing, just using another store for the signatures instead of the CT log.

I'm working on a text-based protocol for making and verifying timestamps of documents and live-streams. It uses SHA3-512 only. https://github.com/mleonhard/tokimark

How is this better than hashing a txt document with a claim which has a timestamp in it?

shasum -a 512 filewithtimestamp.txt

echo I totally made this file five years ago > filewithtimestamp.txt

This approach uses LE as a trusted third party. The date on the cert is valid if you trust letsencrypt.

You can hash the text document, upload the hash to some trusted third party, e.g. if archive.org indexes your website.

It's verifiable. Your approach is just "trust me bro".

I like this concept! Good luck with this.

Reply on news.ycombinator.com