6 ms·

Note that this is an example of the broader timestamped HMAC signature scheme concept. My Google-fu isn't up to the task today. But I'm sure I've seen proposed

Note that this is an example of the broader timestamped HMAC signature scheme concept. My Google-fu isn't up to the task today. But I'm sure I've seen proposed before, eg with something like Bitcoin as the timestamp provider. My OpenTimestamps project is a curious example where I actually made an effort to avoid implementing this by accident. tl;dr: It's a service that does Bitcoin timestamping. In the process, centralized servers generate "calendars" - the database of digests they've timestamped. Now, for disaster recovery the calendar servers have a HMAC with secret key to authenticate digests they've promised to timestamp. The idea being that the HMAC lets us get timestamps back from the community to re-add to the calendar in case the data somehow gets lost. For technical reasons, that HMAC "signs" the current time, and the output of that HMAC gets timestamped securely with Bitcoin. But since OTS servers are not supposed to be trusted, that HMAC digest is deliberately truncated to 64 bits to make it feasible to brute force with significant effort, thus making them not useful as an actual timestamp: https://github.com/opentimestamps/opentimestamps-server/blob/1b191439f66d603d3d5d32a60b691ce8c92746ad/otsserver/calendar.py#L30 https://github.com/opentimestamps/opentimestamps-server/blob... This is ok for their intended purpose, because if you're willing to brute force 64-bits, I'm ok letting you add some junk to the OTS calendars in the event of a disaster. I'm actually considering using that scheme as a trusted timestamping mechanism for OTS, by simply revealing the HMAC keys after they've been timestamped by Bitcoin. They're already derived with a merkle tree from a single seed - each second gets a different HMAC key. To turn that into a verifiable signature you just need to derive all the keys in advance, construct a tweaked version of that merkle tree, and then publish the root. A full signature is then the HMAC output, and a path up the tree to the public root. The advantage for OTS is the amortized size of the signatures would be smaller than a ECC signature, plus being hash based it's a quantum resistant scheme.

londons_explore 6y ago
Your comment here would make a lot more sense to someone outside the project if you have a one-sentence summary about what opentimestamps tries to offer.
- petertodd 6y ago
  Sorry! I wanted to focus on the technical thing, rather than promoting it. OpenTimestamps is a free, open-source, standard for creating timestamps using (mainly) Bitcoin as the root of trust. The calendar server system makes this efficient, using merkle trees to aggregate an unlimited number of timestamp requests into a single Bitcoin transaction, allowing it to be free to use, funded by donations. https://opentimestamps.org/ https://opentimestamps.org/
  - londons_explore 6y ago
    If I'm understanding correctly, it's the same as posting the SHA hash of some secret data to twitter to prove you have some data. At a later time, you can reveal the data, and others can see your earlier tweet and be sure you have had the data since the tweet. Except opentimestamps doesn't need to rely on the honesty of twitter.
    - petertodd 6y ago
      > If I'm understanding correctly, it's the same as posting the SHA hash of some secret data to twitter to prove you have some data. Yup! However, it's important to understand that the only thing OpenTimestamps can do is prove data existed prior to some point in time. It can't prove data is unique. Twitter however can. A simple example is if I want to show off how good I'm at predicting which team is going to win some sports championship. With a Twitter hash commitment I can only pick one team; with OpenTimestamps I could just timestamp every single possible prediction in advance. Which in most years would have worked! Though depending on the sports championship, this year that trick wouldn't have been easy because I'd have to have brute-force timestamped a lot of predictions to have a "Cancelled due to COVID-19" timestamp handy. :)

londons_explore 6y ago

Your comment here would make a lot more sense to someone outside the project if you have a one-sentence summary about what opentimestamps tries to offer.

petertodd 6y ago
Sorry! I wanted to focus on the technical thing, rather than promoting it. OpenTimestamps is a free, open-source, standard for creating timestamps using (mainly) Bitcoin as the root of trust. The calendar server system makes this efficient, using merkle trees to aggregate an unlimited number of timestamp requests into a single Bitcoin transaction, allowing it to be free to use, funded by donations. https://opentimestamps.org/ https://opentimestamps.org/
- londons_explore 6y ago
  If I'm understanding correctly, it's the same as posting the SHA hash of some secret data to twitter to prove you have some data. At a later time, you can reveal the data, and others can see your earlier tweet and be sure you have had the data since the tweet. Except opentimestamps doesn't need to rely on the honesty of twitter.
  - petertodd 6y ago
    > If I'm understanding correctly, it's the same as posting the SHA hash of some secret data to twitter to prove you have some data. Yup! However, it's important to understand that the only thing OpenTimestamps can do is prove data existed prior to some point in time. It can't prove data is unique. Twitter however can. A simple example is if I want to show off how good I'm at predicting which team is going to win some sports championship. With a Twitter hash commitment I can only pick one team; with OpenTimestamps I could just timestamp every single possible prediction in advance. Which in most years would have worked! Though depending on the sports championship, this year that trick wouldn't have been easy because I'd have to have brute-force timestamped a lot of predictions to have a "Cancelled due to COVID-19" timestamp handy. :)