3 ms·

Shameless plug: you can mostly(1) solve the problem of Git PGP signatures becoming unverifiable due to key compromise with my OpenTimestamps software: https://p

Shameless plug: you can mostly(1) solve the problem of Git PGP signatures becoming unverifiable due to key compromise with my OpenTimestamps software: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration tl;dr: it proves data existed in the past. In the case of a PGP signature on a Git commit, that can prove the signature (and the repo contents) were created prior to the key being compromised. 1) Mostly, because sometimes you don't know when the key was compromised.

bawolff 6y ago
Nice to see a non-bullshit application for blockchains :)
- petertodd 6y ago
  Note that OpenTimestamps itself doesn't actually use a blockchain. But while the protocol supports multiple time attestation mechanisms, almost everyone using OTS uses it in conjunction with Bitcoin (the public calendars all timestamp via Bitcoin). Thus almost all OTS timestamps are depending on the Bitcoin blockchain for their timestamp security.
  - Woung1938 6y ago
    Is there a high-to-low level design document to read on how to verify the timestamp? A simple OP_RETURN + hash output in a transaction is dead simple to verify (just get the transaction from any place, see the output, check the timestamp). I'd like to compare OTS with it.
    - petertodd 6y ago
      Not really. But if you understand the basics of how OTS works, it's fairly easy to figure out how to do that with the `ots info` command. Basically, it just prints out the raw commitment operations the timestamp proof performs, letting you follow along. Note that OTS proofs do not have any notion of a transaction in them. Rather, they perform commitment operations that end up at a merkle root of a Bitcoin block (at least in the 99.9999% of proofs that use Bitcoin). With the `--no-bitcoin` option, the OTS client will tell you what block # to look for, and what the merkle should be for the proof to be valid.
dlor 6y ago
We have a similar approach planned in sigstore, but with a slightly different approach to the timestamps by using Transparency Logs. We have some demos here on how to sign git commits: https://github.com/sigstore/cosign/blob/main/FUN.md https://github.com/sigstore/cosign/blob/main/FUN.md The idea is that you can use short-lived keys, bound to certificates via an ACME-style challenge, but based on an email address. The signature goes into a Transparency log to prove it happened while the cert was valid. Then revocation is no longer an issue.
- petertodd 6y ago
  So a big problem with that is that the long term durability of transparency logs is doubtful. Being a record of every SSL cert ever issued, they're an enormous amount of data, and I won't be surprised if actually getting that data in the future becomes hard. OTS just depends on the Bitcoin block headers (megabytes/year), and the databases of timestamps maintained by the public calenders, (a few GB/year; it's new entry per calendar per second). It's a more easier to archive a few GB of data than the tens of terabytes in the public CT logs.
Woung1938 6y ago
Peter, OpenTimestamps are great. Is there a plan to get the raw ots file for embedding in OpenPGP signatures (as notation data) so that I could be sure that the signature was made at given time? (Just like RFC 3161 - style timestamping data).

bawolff 6y ago

Nice to see a non-bullshit application for blockchains :)

petertodd 6y ago
Note that OpenTimestamps itself doesn't actually use a blockchain. But while the protocol supports multiple time attestation mechanisms, almost everyone using OTS uses it in conjunction with Bitcoin (the public calendars all timestamp via Bitcoin). Thus almost all OTS timestamps are depending on the Bitcoin blockchain for their timestamp security.
- Woung1938 6y ago
  Is there a high-to-low level design document to read on how to verify the timestamp? A simple OP_RETURN + hash output in a transaction is dead simple to verify (just get the transaction from any place, see the output, check the timestamp). I'd like to compare OTS with it.
  - petertodd 6y ago
    Not really. But if you understand the basics of how OTS works, it's fairly easy to figure out how to do that with the `ots info` command. Basically, it just prints out the raw commitment operations the timestamp proof performs, letting you follow along. Note that OTS proofs do not have any notion of a transaction in them. Rather, they perform commitment operations that end up at a merkle root of a Bitcoin block (at least in the 99.9999% of proofs that use Bitcoin). With the `--no-bitcoin` option, the OTS client will tell you what block # to look for, and what the merkle should be for the proof to be valid.

dlor 6y ago

We have a similar approach planned in sigstore, but with a slightly different approach to the timestamps by using Transparency Logs. We have some demos here on how to sign git commits: https://github.com/sigstore/cosign/blob/main/FUN.md https://github.com/sigstore/cosign/blob/main/FUN.md The idea is that you can use short-lived keys, bound to certificates via an ACME-style challenge, but based on an email address. The signature goes into a Transparency log to prove it happened while the cert was valid. Then revocation is no longer an issue.

petertodd 6y ago
So a big problem with that is that the long term durability of transparency logs is doubtful. Being a record of every SSL cert ever issued, they're an enormous amount of data, and I won't be surprised if actually getting that data in the future becomes hard. OTS just depends on the Bitcoin block headers (megabytes/year), and the databases of timestamps maintained by the public calenders, (a few GB/year; it's new entry per calendar per second). It's a more easier to archive a few GB of data than the tens of terabytes in the public CT logs.

Woung1938 6y ago

Peter, OpenTimestamps are great. Is there a plan to get the raw ots file for embedding in OpenPGP signatures (as notation data) so that I could be sure that the signature was made at given time? (Just like RFC 3161 - style timestamping data).