david wong

Hey ! I'm David, a security consultant at Cryptography Services, the crypto team of NCC Group . This is my blog about cryptography and security and other related topics that I find interesting.

Elliptic Curve Cryptography March 2014

A video I found about Elliptic Curve Cryptography that talks about the Discreet Logarithm Problem and the Diffie-Hellman Handshake with ECCs. Class is in english, with bits of german and even some french :)

Such a nice lecture, Christof Paar makes me think of a younger Gilbert Strang, seems to be a great professor. I was captivated until the end and I started liking ECCs again :)

comment on this story

Matt Whitlock - Elliptic Curve Cryptography, the Foundation of Bitcoin March 2014

Great lecture from Matt Whitlock, the video's quality is a bit off but the talk is really easy to understand and nicely paced.

And you can tell right away that he's a great educator: "I'll explain first why we use ECC, because in general I don't really understand things when I don't know how they're important" (not the exact words but you get the idea).

comment on this story

Hacking Week February 2014

A teacher from my uni (and who was teaching Programming last semester) is organizing a Hacking Week next week. Signs up are still possible there : http://hackingweek.fr/contestant/list/

It should be a Capture The Flag kind of contest. It should be interesting, although I'm going to ski with some friends so I won't be able to be really into it...

comment on this story

Silk Road 2 : no more bitcoins! February 2014

Seems like the malleability is trendy nowadays. Today this is Silk Road's 2 excuse for stealing its users bitcoins. A lot of drama to come !

I am sweating as I write this. Christmas brought grave news. I cannot adequately express how deeply honored I was by your unconditional support of my staff. I do not expect the same reaction to today’s revelations. This movement is built on integrity, and I feel obligated to be forthright with you. I held myself to a high standard as your leader, yet now I must utter words all too familiar to this scarred community: We have been hacked. Nobody is in danger, no information has been leaked, and server access was never obtained by the attacker. Our initial investigations indicate that a vendor exploited a recently discovered vulnerability in the Bitcoin protocol known as “transaction malleability” to repeatedly withdraw coins from our system until it was completely empty. Despite our hardening and pentesting procedures, this attack vector was outside of penetration testing scope due to being rooted in the Bitcoin protocol itself. This attack hit us at the worst possible time. We were planning on re-launching the new auto-finalize and Dispute Center this past weekend, and our projections of order finalization volume indicated that we would need the community’s full balance in hot storage. In retrospect this was incredibly foolish, and I take full responsibility for this decision. I have failed you as a leader, and am completely devastated by today’s discoveries. I should have taken MtGox and Bitstamp’s lead and disabled withdrawals as soon as the malleability issue was reported. I was slow to respond and too skeptical of the possible issue at hand. It is a crushing blow. I cannot find the words to express how deeply I want this movement to be safe from the very threats I just watched materialize during my watch. I’ve included transaction logs at the bottom of this message. Review the vendor’s dishonest actions and use whatever means you deem necessary to bring this person to justice. More details will emerge as we continue to investigate. Given the right flavor of influence from our community, we can only hope that he will decide to return the coins with integrity as opposed to hiding like a coward. It takes the integrity of all of us to push this movement forward. Whoever you are, you still have a chance to act in the interest of helping this community. Keep a percentage, return the rest. Don’t walk away with your fellow freedom fighters’ coins. DPR2 returned the cold storage. I didn’t run with the gold. But two people alone cannot move us forward. It takes an entire community committing to integrity – and though this crushing blow will not stop us, it sure is a testament to how greedy some bastards truly are. Being a part of this movement might be the most defining thing you do with your entire life. Don’t trade that for greed, comrades. I will fight here by your side, even the greedy bastards amongst us. This community has suffered great financial loss over and over again, and I am devastated that it has happened again under my watch. Hindsight is already suggesting dozens of ways this could have been prevented, but we must march onward. The only way to reverse a community’s greed is through generosity. Our true character is revealed during trying times. If this financial hardship places you at risk of physical harm, contact me directly and I will do my best to help you with my remaining personal funds. Now what. Never again store your escrow bitcoins on a server. Silk Road will never again be a centralized escrow storage. This week has shown the collateral damage we can cause by being a huge target and failing in just one unforeseen area. I am now fully convinced that no hosted escrow service is safe. If I cannot trust myself to keep a hosted escrow solution safe, I cannot trust anyone. Multi-signature transactions are the only way this community will be protected long-term. I am aggressively tasking our devs on building out multi-sig support for commonly-used bitcoin clients. Expect a generous bounty if you have the skill to implement this. Until then. 1. We will never again allow ourselves to be a single point of failure. We will never again host your Escrow wallets. 2. Vendor registration is closed while we regroup. 3. All listings on Silk Road are now No-Escrow (Finalize-Early) for 1-2 months while we implement multi-signature transactions and lobby for mainstream Bitcoin client multi-sig support. 4. All unshipped orders have been cancelled. 5. Vendors may link to other marketplaces on a trail basis until we launch multi-sig, then we will re-evaluate based on community input. We do not want to be a centralized point of failure, but we also do not want to lead our buyers into dangerous waters. 6. From this point forward DO NOT trust markets with centralized escrow. Use multi-signature transactions whenever possible, with trusted third parties as escrow providers. Everything will be offline for 24-48 hours to minimize variables as we continue to investigate. The evidence we have below will be expanded based on our findings. - —————— No marketplace is perfect. Expect any centralized market to fail at some point. This is precisely why we must unite in the decision to decentralize. We are relieved that our security procedures protected user identities, and that no servers were compromised. This was not a worst-case scenario: nobody will be getting arrested from this. Financial loss is terrible, but will not put all of us behind bars. The details we have on the hacker are below. Stop at nothing to bring this person to your own definition of justice. Humbled and furious, Defcon - —————— # Attacker Intel as of 2014-02-13 18:00:00 UTC We normally do not doxx anyone, and hold user information sacred. But this is an extreme situation affecting our entire community, and all three users who have exploited this vulnerability are very much at risk until they approach us directly to assist with any information. Do not reveal any details of the attack. This will jeopardize your reward. Contact us directly. If anyone has purchased or sold to these usernames, expect generous bounties for any information you can contribute which leads to identification. # Attacker 1: (Responsible for 95% of theft) Suspected French, responsible for vast majority of the thefts. Used the following six vendor accounts to order from each other, to find and exploit the vulnerability aggressively. ## Usernames used: narco93 ketama riccola germancoke napolicoke smokinglife Transactions listed at bottom of this file. Finding Attacker 1 is top priority. # Attacker 2: (Responsible for ~2.5% of theft, using same methods towards end of attack lifecycle, likely knows Attacker 1) LethalWeapon – Australia – “stumbled upon” large amount of BTC # Attacker 3: (Responsible for ~2.5% of theft, using same methods towards end of attack lifecycle, likely knows Attacker 1) mrkermit – Australia # Theft Withdrawal Transactions and historical withdrawals by Attacker 1 address,txid_cleaned {Here some big list of withdrawal addresses with the stolen bitcoins}

More info here

comment on this story

Bitcoin Exchanges Under ‘Massive and Concerted Attack’ February 2014

The transaction malleability problem which troubled Mtgox a few days ago has also made Bitstamp shutdown.

Apparently a large scale attack using this problem is going on on multiple exchanges.

Antonopoulos, who is the chief security officer of Blockchain.info, said a DDoS attack is taking Bitcoin’s transaction malleability problem and applying it to many transactions in the network, simultaneously.

The article on coindesk here

It's interesting to watch actually, submit a transaction to the network at the moment and there's a rogue node that will mess with the padding of the signatures and rebroadcast it faster than the original. It confuses the reference client into duplicate display, which is what Gox is relying on for the failed/success display. That they're winning races over the normal related transactions isn't that unnatural as the transaction processing stuff has a 100ms sleep() in the middle of it.

From the discussion over at HN

PS : apparemment l'erreur a été corrigé il y a un an sur le client bitcoin officiel ici

comment on this story

Mtgox statement and transaction malleability February 2014

Mtgox, which is frozen while it is trying to fix its problems, has issued a press released explaining what is the problem

Bitcoin transactions are subject to a design issue that has been largely ignored, while known to at least a part of the Bitcoin core developers and mentioned on the BitcoinTalk forums. This defect, known as "transaction malleability" makes it possible for a third party to alter the hash of any freshly issued transaction without invalidating the signature, hence resulting in a similar transaction under a different hash. Of course only one of the two transactions can be validated. However, if the party who altered the transaction is fast enough, for example with a direct connection to different mining pools, or has even a small amount of mining power, it can easily cause the transaction hash alteration to be committed to the blockchain.

thread on bitcointalk forum

comment on this story