On Wednesday, June 7, 2017 at 9:11:24 PM UTC+2, Peter Todd wrote: > > On Mon, Jun 05, 2017 at 03:17:46PM -0700, Axel wrote: > > > I think that indirection just confuses the issue, so better to put the > > > proof-of-freshness in the signature itself. Fortunately the OpenPGP > > > standard > > > > has something called "signature notation data" that allows you to add > > > arbitrary > > > (signed) data to OpenPGP signatures. In fact, I used to have a cronjob > > > that > > > periodically set my gpg.conf to include a recent blockhash as a > > > proof-of-freshness with the notation bloc...@bitcoin.org > <javascript:>=<blockhash> > > > > > > > > > > Agree. As I said, the best thing would be if a proof of freshness could > be > > part of every signed message. I only suggested proof of freshness as > part > > of the commit as a second-hand option since I didn't know about the > > notational data support. > > Ah good, I misread your original message. Glad we're on the same page! > > > > Even better would be if GPG had the ability to run a command on demand > to > > > get > > > the value a notation should be set too, but as far as I know that > feature > > > doesn't exist yet. That said, I could easily add it to the > OpenTimestamps > > > Client as part of the git commit timestamping support. > > > > > > > What exactly would you add to OTS git support? > > Did you mean adding proof-of-freshness functionality to the git tag > signing > > override provided by OTS? I think that would be very useful. > > Basically, because the OTS git support is a wrapper *around* the gpg > binary, > it's easy for that wrapper to also pass the --set-notation option with a > proof-of-freshness blockhash. This *is* a bit of a hack, but at least on a > technical level it will work, and I can easily add a mechanism for that > wrapper > to get a recent block hash from the OpenTimestamps calendar servers. In > fact, > adding proofs-of-freshness is something I've been thinking about adding to > OpenTimestamps anyway; the main reason I haven't already is that what > exactly > it proves is easily misunderstood. > > > Moreover, I think it would be useful to add something to > > qubes-secpack/utils to help make GPG signatures with a suitably old > block > > hash as notational data. > > Yup, although a tricky part there is you of course need to communicate > with the > outside world to get such a blockhash, which makes this difficult to > implement > on a truly off-line system; I'll admit that it may very well be simpler to > put > the blockhash in the thing being signed (e.g. git commit) rather than in > the > signature as notation data under that circumstance. >
I guess that depends on how split-gpg is implemented. If notational data can be added only on the vault side, then I agree. One good thing is that security does not depend on the ability to verify the hash before using it as freshness proof. It will either produce a proof of freshness or not. It can hardly hurt. Even if you type it up manually, reading it off of another machine and getting a typo in it, it could still serve as proof of freshness: you can argue that getting a hash that close to the real thing would be computationally/statistically/fortune-tellingly unfeasible. It can be compared to citing a news article and forgetting the period character. > > Though, that's another neat thing about the OTS git support: it works just > fine > with Qube's split-gpg support. It'll also work with the signature notation > scheme as qubes-gpg-client-wrapper passes unknown options like the > --set-notation option to GPG (that does smell like a possible security > hole!). > > > > -- > > > https://petertodd.org 'peter'[:-1]@petertodd.org > > > > > > > btw, nice anti-spam measure! > > Thanks! I've had this signature for something like 10+ years, and you're > maybe the > second or third person to comment on it. :) > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/8dc2d304-fb8a-43d8-b2a7-3934fc88bd10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
