TL;DR

If it ain’t broke, don’t throw a vanity address on it... or if one insists on throwing a vanity address on it, apply the same rigorous and ongoing cybersecurity practices one would expect for any code contributing to Hot Wallets. There is a point at which incompetence starts to look like conspiracy, and with extensive warnings and prior art describing the critical security vulnerabilities fundamentally built into the Profanity tool, it is almost unbelievable that Wintermute stored well in excess of $100 million in a Hot Wallet utilizing such an address. 

The second major vanity address security incident of the summer cost ~$160 million 

Another Vanity address generator, an open source tool called Vanity-ETH explains the process of choosing a beginning or an end of your desired address before your browser iterates through random addresses until achieving one compatible with the desired outcome. With the benefit of knowing the public key associated with a vanity address (which are in transaction signatures) the number of possible combinations that one is sifting through to determine the seed public key for a vanity address becomes significantly more manageable. 1inch contributors were able to build an algorithm that surfaced the private keys from any (Profanity generated) vanity address in about as much time as it takes to generate a vanity address (through Profanity). 

The founder and CEO of Wintermute Trading, Evgeny Gaevoy, explained on Twitter that Profanity had not been used for the sake of vanity, for its own sake, but instead to save on gas fees. The Profanity GitHub page was updated by it’s creator and original owner, though they had abandoned the repository previously, on September 15th of 2022, with the following notes: 

“Fundamental security issues in the generation of private keys have been brought to my attention” and “I’ve archived this repository to reduce risk of someone using it. Use something else!”

While hindsight is of course 20/20, digital asset management firm Amber Group proved replication of the Wintermute vanity address hack (or at least achieved the same end results) using a top-range off-the-shelf Macbook computer over about 48hrs. 

Slow responses contribute to well recognized security concerns

1inch published a post on September 13th, a week prior to ~$160 million funds being drained from Wintermute’s hot wallet, warning that funds stored in wallets with addresses generated via the Profanity tool are unsafe and advising that they be moved immediately. 

The possibility of brute forcing private keys associated with addresses generated via Profanity became publicly known as early as January when an issue was raised on the Profanity GitHub. The issue raised concern about the possibility of very quickly (within a few seconds) brute forcing private keys for Profanity addresses. The following line of code was being used: std::mt19937_64 to randomize private keys, in addition to std:random _device which generates a random number to generate a seed. Here’s a blog post from a C++ programmer from 2016 articulating the danger of utilizing this means of generating a random number, one particularly salient excerpt from which is the following: “In fact it’s more dangerous than that: It provides an easy wrong way to do it (use a std::random_device to generate a single int and use that single int as the seed)” 

While this could simply point to the challenges of adopting best practices when developing software, this is a very well known and understood vulnerability. 

There is an increasing awareness in the crypto community of the possibility of DeFi developers building back doors or hidden features that would allow them to siphon off funds in the future. Bearing this in mind while reading the below, one has to somewhat deliberately sustain disbelief that the Wintermute team were not very much inviting this misappropriation of funds. 

Secure Self-Custody of Funds

The lion’s share of the above concerns evaporate when a user leverages DeFi technology such as pre-signed transactions and (thoughtfully designed and properly audited) smart contracts in order to ensure funds can only be accessed by specified parties. Be it the owner of the funds, or some party (or code), unauthorized access to funds is prohibited by design.