Thread by @librehash

1/ This post is going to break down the @monero backdoor that I've been referencing (that got @fluffypony so riled up he had to make false, defamatory claims about me "exit scamming"; imagine he was red in the face banging his keyboard when he wrote this one)

2/ To be clear, this post is referring to this Monero proposal: ccs.getmonero.org/proposals/xiph…; which was successfully funded with 181 XMR, currently worth > $40,000.

Here's the relevant GH repo we're going to dissect = github.com/tevador/monero… (linked from the proposal)

3/ To start, the idea that this wallet repo will save "5 bits reserved" for "future updates", makes zero sense.

The bits he's referring to here are generated from entropy & only exist in an ephemeral, indistinguishable form (how would one select the "5-bits"?)

4/ The first picture is from the backdoored wallet app ; the second one is from the actual BIP39 specification (which this guy tried - and failed, to replicate)

bip39 = github.com/bitcoin/bips/b… (ref.)

4a/ Let's take a step back and breakdown BIP39 real quick.

First priv/pubkeys.

Bitcoin compressed public + private keys are supposed to be 32-bits each. But the public is 33-bits because its a signed integer (the private key is unsigned).

4b/ Every bit = 8 bytes

So 1 byte = 8 bits (2 bytes in hexadecimal)

128 / 32 = 4 bytes / 8 byte hexadecimal ; (take a checksum from each pair)

End up with 4 checksums appended at the end of each.

4c/ That's where the additional '4' comes from in that mnemonic word matrix table

Each checksum = 1 bit (4 bytes) ; 4 checksums = 16 bytes / 32 bytes (hexadecimal)

This is how your classic BTC address gets crafted

From the Bitcoin Wiki = en.bitcoin.it/wiki/Technical…

4d/ You can see the developer of this repo clearly had no clue what they were doing because they erroneously mention "11 bits" (which isn't stored in each word; every 3 words = 32-bit SHA256 'word')

That # was not chosen arbitrarily in BIP39 specification

5/ Moving forward, things get questionable at the KDF part.

For some reason they opted for the HMAC-SHA256 construction vs. SHA512 (which is what Bitcoin uses); why use a different, weaker hash signature there?

5a/ For the sake of thoroughness, this tweet has a picture capturing an excerpt from 'Mastering Bitcoin' written by @aantonop , where it clearly specifies HMAC-SHA512

5b/ Then to make matters worse he makes the *completely* false claim that a seed generated with 128-bits of entropy imbues the same security assurances as an elliptic curve algorithm with a 128-bit strength rating.

Those two concepts are *completely* unrelated to one another.

6/ At the outset, this swap to SHA256 vs. SHA512 may seem trivial, but it isn't - only due to a quirk in how HMAC works.

Keys longer than the byte size of the input 'word' cause the construction to first 'hash the key' "using H"; resulting in pseudo-collisions

7/ Here's where that dev shot himself in the foot.

The SHA256 construction has a 64-byte block size [and takes two 32-bit words as input]. Many don't know this, but SHA256 = two separate processes (there's a midstate cache) <-- this laid foundation for ASIC optimizations

7a/ Remember the bit length that "dev" proffered? They claim to be piping in *154-bits*, which is >128-bit size for the HMAC construction (something this dev stated explicitly themselves)

That means end users *would* find themselves victimized by pseudo-collisions.

7b/ To back up this claim, I wrote up a brief Python script which you can check out on Repl here = replit.com/@Librechain/Py…

8/ You can read the rest of the report here = librehash.org/monero-wallet-…

I tore the repo to pieces.

Strongly reconsider *ever* using Monero for anything - whether you need privacy or not.

@fluffypony is clearly a stooge that's in over his head.