On Sun, Jun 04, 2017 at 05:29:46AM -0700, Axel wrote: > I did not see that pull request. Note however that the pull request makes > qubes-secpack depend on the blockchain in order to prove information > creation *after* a certain point in time, while my suggestion was the > opposite: make the blockchain depend on qubes-secpack in order to prove > information creation *before* a certain point in time. > > I think we should have both. Other things than just canaries can benefit > from being locked into a narrow time period. Maybe it makes sense to have a > folder in qubes-secpack with timing proofs. They would be of two types: > * A proof of freshness, including the last 10 bitcoin block hashes.
Bitcoin block hashes are a chain, so it doesn't make any sense to include more than one, unless you're worried about reorgs. If you are worried about reorgs, for the purpose of time-related proofs, remember that Bitcoin block header times are *very* imprecise, as the consensus doesn't tightly bound the claimed block time for a bunch of reasons. So as a conservative rule of thumb, I would only consider a block header timestamp to have a precision within about a day. With careful analysis you can get tighter bounds than that, but in practice that's rarely very useful anyway. > * A proof of existence, including the identifier of a bitcoin transaction > that includes the hash of either the last git commit, or a more elaborate > statement. IMPORTANT NOTE: As far as I understand, git tags, signed or not, > are not part of the actual commits. If so, proof of existence must also > include the tag signatures. > > Regularly making such timing proofs part of the commit chain will lock all > changes in that repository into a narrow period of time. Each commit is > provably created after all proofs of freshness committed before or included > in it, and before all proofs of existence committed after it. Ideally, > every important commit, such as a release digest or canary, should be > directly preceded by, or include, a proof of freshness and directly > followed by a proof of existence. What exactly are you trying to prevent here? Timestamping commits and canary signatures to prove they existed in the past makes a lot of sense if they're signed, as that allows you to establish that those signatures were created prior to a compromise. Additionally proving that canaries were created after a certain point in time is useful to prevent forward dating. But what attack does the latter type of proof prevent when applied to git commits? -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170605113354.GA30553%40savin.petertodd.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
