November Progress:
Security Vulnerability
As shared on Twitter yesterday:
Kurt, a long-time GRIN community member, contacted Charlie and I to inform us of a vulnerability in the design for non-interactive transactions. While the attack is difficult to perform in practice, it does allow for theft of funds if the conditions line up just right.
This attack is rather technical, and difficult to understand without first learning all of the crypto behind MWEB. Very informally, it works like this:
- Alice sends 2 coins to Bob:
- coin 1 = 10 LTC
- coin 2 = 20 LTC
- Bob creates 2 transactions, 1 to Charlie, and another back to Alice, and sends them at roughly the same time:
- tx1 = spend coin 1 to send 8 LTCs to Alice (8 LTC Alice, 2 LTC Change)
- tx2 = spend coin 2 to send 15 LTCs to Charlie (15 LTC Charlie, 5 LTC Change)
- Alice changes tx1 to spend coin 2 instead, keeping the additional 10 LTCs for herself:
- tx3 = spend coin 2 to send 18 LTCs to Alice and 2 LTC back to Bob as Change
- tx1 & tx2 dropped and replaced with tx3
There are a number of reasons why this attack would fail in practice nearly every time. But the consequences if it did succeed would be very serious, so it was obvious this was something we had to prevent.
We are very grateful for Kurt taking the time to study MWEB’s design, and for reaching out to share this attack with us. Due to the importance of the finding, Charlie generously donated his own money to pay Kurt a well-deserved 0.15 BTC bounty.
The Fix
Considering the proximity to the planned release date, panic started to set in. Fortunately, I realized there’s a relatively straightforward fix for the attack that consists of introducing a new public key in each input that prevents reuse of input signatures.
At the same time we were working through the details of the attack & fixes, I was put in contact with some top-notch cryptographers who offered to do a security audit of our design, which they were considering to use as a starting point for another project they were working on.
The need for a more formally documented design became evident, so I spent the next few weeks rewriting LIP-0004 into a more complete and formally specified design, making minor tweaks along the way to harden it where I could. Clearly, I should’ve done this from the beginning, because we’ve had nearly as many reviewers of LIP-0004 in this past month as we have for the previous 1.5 years 
While I would’ve loved to have all of these eyes on the design long ago, I’m thrilled about all of the feedback I’ve received.
Unfortunately, some changes do need to be made to the code to now match the new design, which means a few more more weeks of dev work. Fortunately, nearly all of the changes will be in the libmw subproject, which is highly modularized and heavily tested. This is great news, since it means the changes should be easier to make, test, and most importantly, review. This review can be carefully performed by the other LTC developers, so I don’t believe it’s necessary to send the changes back to the auditors. This will have an impact on release date, but the delay should be minimal.
Release Process
I mentioned last month that the release build process was time-consuming, and the scripts were outdated, so I spent some time cleaning all of the old scripts up, and creating a simpler, more automated build process. The build scripts and verification keys are going to be maintained in a separate repo going forward. Right now, the new ltc-release-builder is just under my personal github account, but if it works out well for the MWEB release, we’ll get that moved to litecoin’s github org.
Timeline updates
-
I’ve chosen to push the release to January to ensure we have enough time to fix the vulnerability found. Hopefully that will be the last time
. wenmweb.com is once again up-to-date. -
v0.21.1 any day now™ for real this time™
