Hacker News new | past | comments | ask | show | jobs | submit login

In this example it is key rotation, but you do not know when your key will expire, so you cannot put that in the message. Imagine you have a key, and later realize it may or may not be compromised, so you decide to rotate.

You can be in the habit of writing "I signed this message at date K" but if any of your old keys are compromised, the hacker can sign a new message with today's date to spoof a new rotation event. Without ordering these events by time, you cannot know which is the newest.

One solution is to have a log showing the timestamped key rotations. A company can store everybody's timestamped key rotations on a sqlite database and promise it won't ever be modified, or you can put these state changes in a distributed ledger. If the value of the key rotation events outweighs the cost of submitting transactions to the ledger, it may be worth it. This is unrealistic with Eth L1 but more realistic in something like a recursive zk rollup on L2.




The documents themselves are the log. You don't need "zk rollup on L2" to make a verified chain of documents. All that's left is the distribution method.

For that, you put them on your website, using proper security. You put them somewhere where you (and your users) have legal recourse if something goes wrong. That is the safest place to put your public keys.

Also, if your keys are compromised, a blockchain solution is completely and forever corrupted. A website is only corrupted for a few hours until you regain control.


A document is not a ledger. The blockchain is the distribution mechanism.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: