On Mon, Jun 05, 2017 at 11:15:33AM -0700, Axel wrote: > > 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.
Ah, but see, since Bitcoin blocks are in a chain, a block hash ten blocks deep is only invalidated in the event of an (extremely) rare re-org more than ten blocks deep. > > 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. Right, but if you don't need better precision, just picking a *single* blockhash, say, ten blocks back is totally fine. On average that'd be a block a bit over an hour and a half old. The only reason you'd want to include *more* than one block hash is to try to get better precision, with a fallback in case of a reorg. If you're picking a blockhash 10 blocks back, on average that'd be a bit over an hour and a half old, which is well within the timing precision you can expect from Bitcoin anyway, and certainly good enough for our application. So my advice would be to keep it simple and just include a single block hash. FWIW, the actual consensus rules for Bitcoin blocktimes require the following two conditions to be true: 1) nTime > the median nTime of the past 11 blocks This rule ensures nTime will move forward, eventually, though miners have a lot of lee-way to backdate their blocks. A miner with negligible hashing power can backdate a block they create at no cost to themselves on average something like an hour or so, assuming the block times of all other miners are honest. If the backdating hashing power is non-negligible - say 50% - it's quite plausible they'd be able to create backdated blocks with block times that are multiple hours behind what they should be. If 100% of hashing power is backdatin blocks, the only thing limiting the attack is at some point they'll cause difficulty to increase, but that'd be a scenario where block times have been backdated by multiple *days* at least. Fortunately, by the time we're talking about multiple hours/days of backdating, it's a very public attack that probably would get noticed. But backdating an hour or two is something miners could definitely get away with. 2) nTime < now + 2 hours This attempts to prevent miners from producing forward dated blocks, which among other things, could be used to artifically drive difficulty down. But because there's no universal and reliable notion of time, it's a really dodgy rule that itself can be used as an attack vector - miners can be in a position where they *want* part of the network to (initially) reject their blocks. If miners do start forward dating their blocks for whatever reason, I'd expect to see enforcement of this rule to break down; what happens then is hard to know. Again, the only good thing is that a forward dating attack is pretty public, so we'd at least find out it had happened and could respond accordingly. Finally, I should point out that providing incentives for miners to mess with block times is a potential threat to Bitcoin as a whole; we'd all be better off if people design systems that are robust to such attacks, to avoid giving attackers incentives to do them in the first place. tl;dr: Please round off nTime to the nearest day. :) > > 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. While it's somewhat niche, I agree that you do make a good case there for the at utility of proof-of-freshness when applied to PGP signatures in general. In addition to split-GPG, that'd also be useful for the quite common case of signing with a PGP smartcard. I will make the point though that the proof-of-freshness is only valid for proving that the *signature* was freshly created, not the Git commit itself. The reason is simple: the proof-of-freshness is only useful because it's difficult to recreate the signature; the git-commit *by itself* doesn't have that property. > 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. If you put the proof-of-freshness in the git commit, what you've actually done is made a proof-of-freshness for the *signature* on the git commit, just with one step of indirection. 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 blockh...@bitcoin.org=<blockhash> 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. -- 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/20170605195352.GA928%40savin.petertodd.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
