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.

Twitter is giving up on encrypting direct messages... March 2014

...At least for now.

This shows how unnecessary encrypting is sometimes. Some people like to encrypt and encrypt everything, and don't consider a solution "usable" if it not fully protected.

I'd argue that twitter has always been a very "public" and "exhibitionist" kind of websites where the private messages have never been a core feature (and it's actually not a really well done message system) and no user is obviously going to use it for "serious" matters. So why spend time encrypting it ?

http://www.theverge.com/2014/3/19/5523656/twitter-gives-up-on-encrypting-direct-messages-at-least-for-now

comment on this story

Hashes, MACs, Signatures March 2014

I was very confused when I was introduced to signatures and macs because I thought they were just Hashes. I got to understand what it was and... it's actually super simple.

Here's a great explanation on the crypto stackexchange but here's mine:

  • I have a huuuge message that I want to transfer to a friend. I'm scared some of the words would change during transit. Solution? I just hash it and send the hash with the message. hash = Hash(message). A hash is pretty small (for example a md5 hash is 32 characters) so it's no trouble. My friend then receives the message and the hash, he can Hash(message) it and see if it gives him the same hash. If it doesn't then he knows that the message was changed and he can ask me for a new copy.

You can also call that an unkeyed hash, simply because it doesn't use a key. You just apply the algorithm to the message, no other arguments are given to the hash function.

  • Okay now, We had some problems because some bad guy has sent numerous bad messages to my friends pretending he was me. I still want to hash my message but I also want to tell my friend it was me who wrote it. So, like a symmetric cipher, I generate a key that I share with my friend. And I hash my message with that key Hash = HMAC(key, message). My friend can now hash it with the same key when he receives the message and see that we have the same hash.

We just used a (symmetric) keyed hash or a HMAC (Hash-based message authentication code). Note that we could have used a MAC based on a Cipher as well (CMAC).

  • So me and my friend have been writing many messages to a community of coders. We want to sign each messages with our name, but that's not enough, another bad guy is posting bad stuff signed with our names on different websites. So let's use a Hash that people can verify, like an asymmetric cipher, we generate both a secret key and a public key, we hash the message with our secret key and we post the message, the hash and the public key. Hash = Sign(secret_key, message). People can then verifiy that Hash with the public key. Voila ! We just used a Signature or how I like to call them a asymmetric keyed hash. It allows for integrity of data, thanks to the hash, authentification of the authors, thanks to the secret key (this is a MAC), non-repudiation thanks to the public key (and now we have a signature).

So if you got it right, Hash < Mac < Signature. They're all useful and you should use the one relevant according to the context.

I'll just copypasta the table on the stackoverflow answer, because it's a real nice summary:

Cryptographic primitive | Hash |    MAC    | Digital
Security Goal           |      |           | signature
------------------------+------+-----------+-------------
Integrity               |  Yes |    Yes    |   Yes
Authentication          |  No  |    Yes    |   Yes
Non-repudiation         |  No  |    No     |   Yes
------------------------+------+-----------+-------------
Kind of keys            | none | symmetric | asymmetric
                        |      |    keys   |    keys
comment on this story

I made a LTC chart March 2014

I wanted something I could display on my TV continuously, I think I did a pretty good job.

This shows how much is a LTC in US dollar in real time, it's made with a bit of python and a bit of javascript, you can check it here

ltc chart

ltc chart light

comment on this story

Atom invites March 2014

I have two invites for the new IDE by github. I can't try it because I don't own a mac and there are no versions for windows at the moment (not even linux). Weird, but eh, if you own a mac and want an invite just ask me in the comments !

https://atom.io/

comments (2)

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