Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-01 📝 Original message:That seems overly ...
📅 Original date posted:2014-01-01
📝 Original message:That seems overly complicated, there's no need for the Bitcoin protocol to
be involved. Deterministic builds with threshold signed updates are a
problem the entire crypto community is now interested in solving - any
solution should be generic.
Really all you need is an update engine that allows a CHECKMULTISIG type
approach. When the update engine is not under our control, i.e. on Android,
Shoup style RSA threshold signatures can potentially work (though I must
admit, I have never found time to play with the implementation I have for
that algorithm).
On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> I didn't know about the dedicated server meltdown, it wasn't any of my
> infra. Anyway, my previous offer still stands.
>
> One less 'security theater' approach would be if we could provide
> forward-validation of updates using the blockchain. It's always going to be
> up to the user the first time they install the wallet to verify the
> provenance of the binaries/source. From that point forward, we could make
> it easier if the wallet could detect updates and prove they were valid.
>
> This could be as simple as hard-coding a public key into the client and
> checking a signature on the new binaries. But it could also be more
> interesting...
>
> For example, a well known address on the blockchain corresponds to
> multi-sig with keys controlled by developers (or whatever key policy the
> release team wants to impose). A spend from that address announces a new
> release, and includes the expected hash of the file.
>
> You would probably need some way to handle the different release targets.
> A more rigorous approach could identify all the various releases in terms
> of a BIP32 xpubkey whose branches would correspond to the different release
> trains and platform builds. Spends from a node announce the release and the
> expected hash.
>
> This provides zero benefit if the wallet software is already compromised,
> but I think this would allow trusted automatic update notification, and a
> trusted way to deliver the expected hashes. It also might resolve some of
> the consternation around when a release is truly "released", if that's
> really a problem.
>
> I'm not sure how far along the slope you would want to go; 1) announcing
> updates in the UI, 2) providing a button the user could click to verify a
> binary matches its expected hash, 3) click to download and verify the
> upgrade matches the expected hash, 4) click to upgrade
>
> Formalizing the release process around a set of privkeys (or split shares
> of keys) may raise its own set of questions.
>
> For the download itself, I've heard the advocates of announcing
> availability on the blockchain leading to a BitTorrent magnet link, but I
> also understand objections to adding an entire BitTorrent stack into a
> wallet.
>
> On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike at plan99.net> wrote:
>
> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>>
>
> Oh, it did? When was that? I must have missed this excitement :)
>
> Any idea how much load it had?
>
> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>>
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS pretty
> hard, and saying that based on the access to the source docs some of their
> MITM attacks can't beat TLS. It appears that they have the capability to do
> bulk MITM and rewrite of downloads as Drak says but *not* when TLS is
> present, that would force more targeted attacks. So to me that implies that
> TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then
> that'd be an issue. We could consider hosting downloads on AppEngine or
> something else that can handle both high load and TLS.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140101/6f3e8e26/attachment.html>;
📝 Original message:That seems overly complicated, there's no need for the Bitcoin protocol to
be involved. Deterministic builds with threshold signed updates are a
problem the entire crypto community is now interested in solving - any
solution should be generic.
Really all you need is an update engine that allows a CHECKMULTISIG type
approach. When the update engine is not under our control, i.e. on Android,
Shoup style RSA threshold signatures can potentially work (though I must
admit, I have never found time to play with the implementation I have for
that algorithm).
On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> I didn't know about the dedicated server meltdown, it wasn't any of my
> infra. Anyway, my previous offer still stands.
>
> One less 'security theater' approach would be if we could provide
> forward-validation of updates using the blockchain. It's always going to be
> up to the user the first time they install the wallet to verify the
> provenance of the binaries/source. From that point forward, we could make
> it easier if the wallet could detect updates and prove they were valid.
>
> This could be as simple as hard-coding a public key into the client and
> checking a signature on the new binaries. But it could also be more
> interesting...
>
> For example, a well known address on the blockchain corresponds to
> multi-sig with keys controlled by developers (or whatever key policy the
> release team wants to impose). A spend from that address announces a new
> release, and includes the expected hash of the file.
>
> You would probably need some way to handle the different release targets.
> A more rigorous approach could identify all the various releases in terms
> of a BIP32 xpubkey whose branches would correspond to the different release
> trains and platform builds. Spends from a node announce the release and the
> expected hash.
>
> This provides zero benefit if the wallet software is already compromised,
> but I think this would allow trusted automatic update notification, and a
> trusted way to deliver the expected hashes. It also might resolve some of
> the consternation around when a release is truly "released", if that's
> really a problem.
>
> I'm not sure how far along the slope you would want to go; 1) announcing
> updates in the UI, 2) providing a button the user could click to verify a
> binary matches its expected hash, 3) click to download and verify the
> upgrade matches the expected hash, 4) click to upgrade
>
> Formalizing the release process around a set of privkeys (or split shares
> of keys) may raise its own set of questions.
>
> For the download itself, I've heard the advocates of announcing
> availability on the blockchain leading to a BitTorrent magnet link, but I
> also understand objections to adding an entire BitTorrent stack into a
> wallet.
>
> On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike at plan99.net> wrote:
>
> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>>
>
> Oh, it did? When was that? I must have missed this excitement :)
>
> Any idea how much load it had?
>
> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>>
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS pretty
> hard, and saying that based on the access to the source docs some of their
> MITM attacks can't beat TLS. It appears that they have the capability to do
> bulk MITM and rewrite of downloads as Drak says but *not* when TLS is
> present, that would force more targeted attacks. So to me that implies that
> TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then
> that'd be an issue. We could consider hosting downloads on AppEngine or
> something else that can handle both high load and TLS.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140101/6f3e8e26/attachment.html>;