I recently had solar panels and a battery storage system from GivEnergy installed at my house. A major selling point for me was that they have a local network API which can be used to monitor and control everything without relying on their cloud services. My plan is to set up Home Assistant and integrate it with that, but in the meantime, I decided to let it talk to the cloud. I set up some scheduled charging, then started experimenting with the API.

The next evening, I had control over a virtual power plant comprised of tens of thousands of grid connected batteries.

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”.

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.

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.

I’ve seen a lot of people expressing concern that Bitcoin mining ASICs are going to lead to some sort of password cracking apocalypse.

They won’t.