Last week, a backdoor was discovered in xz-utils. The backdoor processes commands sent using RSA public keys as a covert channel. In order to prevent anyone else from using the backdoor, the threat actor implemented a cryptographic signature check on the payload.

I have seen a number of people claim that this would necessarily result in an obviously invalid RSA public key, or at least one with no corresponding private key.

This is incorrect, and someone nerd sniped me into proving it.

If you’re like most people, there’s a good chance that it’s been years since you’ve sent an email that wasn’t cryptographically signed. You don’t use PGP, you say? Well, even if you are not signing your email, your provider is almost certainly doing it for you. Plausible deniability has been tossed aside in the name of stopping spam, but it doesn’t have to be.

Sometimes hacking requires doing things that, while possible to do with some algorithm, simply aren’t supported by any existing implementation. Usually for good reason. A good example of this that I’ve run into in the past is needing to initialize a hash algorithm with a specific state. There’s really not any reason to do this unless you’re trying to execute a length extension attack, and with the exception of HashPump (which was written specifically for that use case) I’m not aware of any library that supports it. I recently ran into this with problem with RSA.

It recently came to my attention that John McAfee has been advertising a cryptocurrency hardware wallet from a company called Bitfi, with the claim that it is “unhackable”. There’s even a $250,000 bounty to hack it. I do not have one of the actual devices in my possession, but from my review of the publicly available “source code” [PDF] and their private key calculator, my conclusion is that their product is most charitably described as a “footgun”.

At DEFCON 22, Dan Kaminsky and I talked a little bit about something I built which he dubbed “Storybits”. Storybits can reversibly transform short strings of binary data into a series of words designed to produce a mental image. Order of the words does not matter, and many typos can be corrected automatically. I already had working code at the time of that talk, but since then it’s just been sitting around on my computer. People have been asking about it, so I put it up on GitHub, though it’s still a hacky prototype. I’ve thrown together a demo and written a bit about how it works.

Since its release at DEFCON 23, I’ve done quite a bit of work on brainflayer. First, I added support for a few other brainwallet-like schemes and hex-encoded private keys. Then, in October, I integrated some code provided by Dr. Nicolas T. Courtois and Guangyan Song from UCL that sped up brainflayer by about 150%. With a subsequent optimization that yielded a further 65% speedup, it is now over four times faster than the initial release.

In January, I added specialized code for brute force private key search. While trying it out, I found something very interesting.

By the time I had a look into Craig Wright’s blog post that seemed to imply that he is Satoshi, others had already pointed out that the signature was copied from a 2009 transaction. The contents of the “Sartre” file, however, were still a mystery. Dan Kaminsky had a blog post up analyzing the commands from CW’s post, but hadn’t been able to figure that bit out, so he asked me to have a look.

In the spring of 2014, I found a bug in several browsers, including Epiphany, Xombrero, Opera Mini and Midori. They were loading subresources, such as scripts, from HTTPS servers without doing proper certificate validation. I tracked this down to some bad defaults in webkit which have since been fixed.

On August 7^th I will be giving a talk at DEF CON about cracking brainwallets. As part of that talk, I will be releasing a fast brainwallet cracker. I’m writing this post to provide a little insight as to why I’m giving away a tool that could be used to steal. I also hope that people who are currently using brainwallets will take notice and move to a more secure storage method.

GitHub’s implementation of git over ssh identifies accounts (for purposes of access control) solely by ssh public key. As a consequence, a particular public key can be associated with, at most, one account. Deploy keys are even more restricted - they can only be associated with a single repository. While ssh can try several keys, GitHub doesn’t know what you’re trying to access until after you authenticate, so a workaround is required to select the right key.