On Monday, June 5, 2017 at 1:34:01 PM UTC+2, Peter Todd wrote: > > 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. >
Agree. reorgs are the only reason to include more than one, but 10 seems like overkill. Reorgs aren't even an ultimate threat in this case, we don't have a double-spending problem or similar. The only reason for us to worry about reorgs is future availability of the blockchain data. 3 blocks is generally considered very secure, so maybe we can go with that. > > 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. > I agree that we don't need more precision than a day. As I said above, the only worry is that a reorg would make the block data unavailable in the future, rendering the proof unverifiable. > > > * 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? > Using proof of freshness to prevent forward dating can be applied to more than just canaries. Imagine an attacker that has temporary use-access but not read-access to a private key, e.g. by compromising one side of split GPG in a setup where the vault VM does not show the user what is about to be signed. In this case, the attacker might be interested in signing a malicious Qubes .iso image, and in order to prevent the developers to refute the .iso, the attacker also signs a key revocation that is sufficiently forward-dated to not raise suspicion about the .iso. I admit this example is somewhat far-fetched, but the point is that more than just canaries can benefit from forward-dating prevention. The stronger argument for doing this is that it is the conservative thing to do: Nothing seems to become less secure by preventing forward-dating, and it does essentially remove an attack surface. It should be standard procedure to prove timing of everything that is released, meaning both proof of freshness and proof of existence. A proof of freshness only proves anything for things that depend on it. For example, a key revocation that does not include a proof of freshness, isn't proven to be created after that point in time. The best thing would be if a proof of freshness could be part of every signed message, including .iso digests and key revocations. If this seems like too much work, I believe the next best thing would be to adopt a standard procedure that everything that is signed MUST also be part of a signed git commit that includes a proof of freshness. With this rule, users that trust the key owners (which we must do anyways), can trust that a digest published in a signed git commit was created approximately around the point in time of it's corresponding proof of freshness. > > -- > 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/df96b953-6e59-4fd1-a5d3-b7cb0378f295%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
