5 ms·

> I don’t have a record of every signature I made Use opentimestamps git wrapper. Each commit is signed and timestamped. When you revoke your key, the original

> I don’t have a record of every signature I made Use opentimestamps git wrapper. Each commit is signed and timestamped. When you revoke your key, the original signed commit is still timestamped, presumably before your revocation date. https://github.com/opentimestamps/opentimestamps-client https://github.com/opentimestamps/opentimestamps-client https://opentimestamps.org/ https://opentimestamps.org/

CaliforniaKarl 9y ago
Dude. That looks awesome. It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), but that would probably need messing with GPG in some way. (What I mean is, a GPG signature includes a space for "sub-packets" of information, stored in in "length-type-value" form. See RFC 4480 Section 5.2.3 for the overall signature packet format. The OpenTimestamp data could be embedded as a sub-packet, causing its content to also be signed.) It looks like this site was posted 12 days ago by handpickednames in https://news.ycombinator.com/item?id=15456521 https://news.ycombinator.com/item?id=15456521, but it didn't get must attention. I think people should check it out! (Disclaimer: I don't have any position in Bitcoin or blockchain right now.)
- hdhzy 9y ago
  > It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), Interesting, I took a sample signature from here [0], saved that to file and run `gpg --list-packets gitsig.asc`: # off=0 ctb=89 tag=2 hlen=3 plen=284 :signature packet: algo 1, keyid 5D3EB2F8800430EB version 4, created 1399174181, md5len 0, sigclass 0x00 digest algo 2, begin of digest 65 b4 hashed subpkt 2 len 4 (sig created 2014-05-04) subpkt 16 len 8 (issuer key ID 5D3EB2F8800430EB) data: [2047 bits] It looks like it is timestamped with date 2014-05-04T03:29:41.000Z. The tag itself also has Date header, usually the tag is created and signed at the same time. [0]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work OpenTimestamps protects against someone backdating signatures. If they control the key they can create signatures with arbitrary dates but they can't put them in the blockchain in any place. So basically that gives "proof of existence" that the given signature existed at least at that exact point of time. Disclaimer: I never used OpenTimestamps but rather Bitcoin Core JSON interface to timestamp things (it's 3 simple commands to publish OP_RETURN transaction). For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
  - petertodd 9y ago
    > For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency To be clear, OpenTimestamps doesn't require you to spend money to create a timestamp, as it has a set of public calender servers that pool timestamp requests, allowing all OTS users to share the same BTC transaction (which itself is paid out of donations).
    - deleted 9y ago
      [deleted]
  - CaliforniaKarl 9y ago
    Sorry, I should have been clearer. Here's what I meant to say: >It kindof annoys me that the _OpenTimestamp_ wasn't somehow worked into the signature itself (like as a sub-packet),
- petertodd 9y ago
  > but that would probably need messing with GPG in some way. That's exactly why I didn't do that: the OpenPGP standard is extremely complex, good libraries to do that kind of thing just don't exist, and it was unclear what compatibility issues I'd be adding if I did that.
petertodd 9y ago
I also have a blog post describing the Git timestamping use-case: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration

CaliforniaKarl 9y ago

Dude. That looks awesome. It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), but that would probably need messing with GPG in some way. (What I mean is, a GPG signature includes a space for "sub-packets" of information, stored in in "length-type-value" form. See RFC 4480 Section 5.2.3 for the overall signature packet format. The OpenTimestamp data could be embedded as a sub-packet, causing its content to also be signed.) It looks like this site was posted 12 days ago by handpickednames in https://news.ycombinator.com/item?id=15456521 https://news.ycombinator.com/item?id=15456521, but it didn't get must attention. I think people should check it out! (Disclaimer: I don't have any position in Bitcoin or blockchain right now.)

hdhzy 9y ago
> It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), Interesting, I took a sample signature from here [0], saved that to file and run `gpg --list-packets gitsig.asc`: # off=0 ctb=89 tag=2 hlen=3 plen=284 :signature packet: algo 1, keyid 5D3EB2F8800430EB version 4, created 1399174181, md5len 0, sigclass 0x00 digest algo 2, begin of digest 65 b4 hashed subpkt 2 len 4 (sig created 2014-05-04) subpkt 16 len 8 (issuer key ID 5D3EB2F8800430EB) data: [2047 bits] It looks like it is timestamped with date 2014-05-04T03:29:41.000Z. The tag itself also has Date header, usually the tag is created and signed at the same time. [0]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work OpenTimestamps protects against someone backdating signatures. If they control the key they can create signatures with arbitrary dates but they can't put them in the blockchain in any place. So basically that gives "proof of existence" that the given signature existed at least at that exact point of time. Disclaimer: I never used OpenTimestamps but rather Bitcoin Core JSON interface to timestamp things (it's 3 simple commands to publish OP_RETURN transaction). For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
- petertodd 9y ago
  > For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency To be clear, OpenTimestamps doesn't require you to spend money to create a timestamp, as it has a set of public calender servers that pool timestamp requests, allowing all OTS users to share the same BTC transaction (which itself is paid out of donations).
  - deleted 9y ago
    [deleted]
- CaliforniaKarl 9y ago
  Sorry, I should have been clearer. Here's what I meant to say: >It kindof annoys me that the _OpenTimestamp_ wasn't somehow worked into the signature itself (like as a sub-packet),
petertodd 9y ago
> but that would probably need messing with GPG in some way. That's exactly why I didn't do that: the OpenPGP standard is extremely complex, good libraries to do that kind of thing just don't exist, and it was unclear what compatibility issues I'd be adding if I did that.

petertodd 9y ago

I also have a blog post describing the Git timestamping use-case: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration