From: Cameron Garnham <da2ce7@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Cc: cve-request@mitre•org, Jeremy Rubin <jeremy.l.rubin.travel@gmail•com>
Subject: Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability
Date: Wed, 24 May 2017 20:59:28 +0300 [thread overview]
Message-ID: <A2E37BF2-F1FF-4273-A0CE-08384D41E450@gmail.com> (raw)
In-Reply-To: <CAJowKg+MZfdfSkZQQutKsFY=rcQSAhLtpRT7dAEH=qyYPNN67A@mail.gmail.com>
Hello Bitcoin-Dev,
A quick update that CVE-2017-9230 has been assigned for the security vulnerability commonly called ‘ASICBOOST’:
"The Bitcoin Proof-of-Work algorithm does not consider a certain attack methodology related to 80-byte block headers with a variety of initial 64-byte chunks followed by the same 16-byte chunk, multiple candidate root values ending with the same 4 bytes, and calculations involving sqrt numbers. This violates the security assumptions of (1) the choice of input, outside of the dedicated nonce area, fed into the Proof-of-Work function should not change its difficulty to evaluate and (2) every Proof-of-Work function execution should be independent.”
I would like to especially thank the CVE team at Mitre for their suggested description that was more appropriate than my proposed text.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
Cameron.
> Begin forwarded message:
>
> From: <cve-request@mitre•org>
> Subject: Re: [scr-xxxxx] Bitcoin - All
> Date: 24 May 2017 at 18:52:22 GMT+3
> To: <da2ce7@gmail•com>
> Cc: <cve-request@mitre•org>
>
> Signed PGP part
> > [Suggested description]
> > The Bitcoin Proof-of-Work algorithm does not consider a certain attack
> > methodology related to 80-byte block headers with a variety of initial
> > 64-byte chunks followed by the same 16-byte chunk, multiple candidate
> > root values ending with the same 4 bytes, and calculations involving
> > sqrt numbers. This violates the security assumptions of (1) the choice
> > of input, outside of the dedicated nonce area, fed into the
> > Proof-of-Work function should not change its difficulty to evaluate
> > and (2) every Proof-of-Work function execution should be independent.
> >
> > ------------------------------------------
> >
> > [Additional Information]
> > ASICBOOST, originality promoted as a patented mining optimisation(1).
> > Has under detailed study (2), become regarded as an actively exploited
> > (3), security vulnerability (4), of Bitcoin.
> >
> > The Bitcoin Proof-of-Work Algorithm is dependent on the following two
> > security assumptions that are both broken by 'ASICBOOST':
> > 1. The choice of input, outside of the dedicated nonce area, fed into
> > the Proof-of-Work function should not change it's difficulty to
> > evaluate.
> > 2. Every Proof-of-Work function execution should be independent.
> >
> > 'ASICBOOST' creates a layer-violation where the structure of the input
> > outside of the dedicated nonce area will change the performance of the
> > mining calculations (5). 'ASICBOOST' exploits a vulnerability where
> > the Proof-of-Work function execution is not independent (6).
> >
> > References:
> > (1) Original Whitepaper by Dr. Timo Hanke: https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
> > (2) Academic Write-up by Jeremy Rubin: http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> > (3) Evidence of Active Exploit by Gregory Maxwell:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
> > (4) Discussion to assign a CVE Number, by Cameron Garnham:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html
> > (5) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan Grant:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> > (6) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
> >
> > The patent holder of this particular security vulnerability has a dedicated website: https://www.asicboost.com/
> >
> > ------------------------------------------
> >
> > [VulnerabilityType Other]
> > Cryptocurrency Mining Algorithm Weakness
> >
> > ------------------------------------------
> >
> > [Vendor of Product]
> > Bitcoin
> >
> > ------------------------------------------
> >
> > [Affected Product Code Base]
> > Bitcoin - All
> >
> > ------------------------------------------
> >
> > [Affected Component]
> > Bitcoin
> >
> > ------------------------------------------
> >
> > [Attack Type Other]
> > Cryptocurrency Proof-of-Work Algorithm Weakness
> >
> > ------------------------------------------
> >
> > [CVE Impact Other]
> > Creation of Perverse Incentives in a Cryptocurrency
> >
> > ------------------------------------------
> >
> > [Attack Vectors]
> > Bitcoin Mining Unfair Advantage
> > Bitcoin Layer-Violations Creating Perverse System Incentives
> >
> > ------------------------------------------
> >
> > [Reference]
> > https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
> > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
> >
> > ------------------------------------------
> >
> > [Has vendor confirmed or acknowledged the vulnerability?]
> > true
> >
> > ------------------------------------------
> >
> > [Discoverer]
> > Original Discovery: Dr. Timo Hanke and Sergio Lerner. Proof of Active
> > Exploit: Gregory Maxwell. CVE Reporter: Cameron Garnham
>
> Use CVE-2017-9230.
>
>
> --
> CVE Assignment Team
> M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
> [ A PGP key is available for encrypted communications at
> http://cve.mitre.org/cve/request_id.html ]
>
prev parent reply other threads:[~2017-05-24 17:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 13:44 Cameron Garnham
2017-05-18 13:57 ` James Hilliard
2017-05-18 14:59 ` Tier Nolan
2017-05-19 7:32 ` Cameron Garnham
2017-05-18 19:28 ` Ryan Grant
[not found] ` <CAJowKgLurok+bTKrt8EAAF0Q7u=cEDwfxOuQJkYNKieFpCPErQ@mail.gmail.com>
[not found] ` <CAJowKg+r3XKaoN3ys3o3FWhpJ3w8An1q0oYMmu_KzDfNdzF8Vg@mail.gmail.com>
[not found] ` <CAJowKgKf22b2jjRbmG+k53g4bOzXrk7AHVcR02xqXPU8ZLJhaQ@mail.gmail.com>
[not found] ` <CAJowKg+LAcVCsH7gbuZhKnnv8p5=WXqNCs5oqub3bacRpQ7n9w@mail.gmail.com>
2017-05-19 7:16 ` Erik Aronesty
2017-05-24 17:59 ` Cameron Garnham [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A2E37BF2-F1FF-4273-A0CE-08384D41E450@gmail.com \
--to=da2ce7@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=cve-request@mitre$(echo .)org \
--cc=jeremy.l.rubin.travel@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox