Let’s talk about BLS signatures

In a bit of a mini-rant on Twitter, Bram Cohen has announced that Chia Network is using a legacy implementation of BLS Signatures (v2) where the new draft (v4) implements a slightly updated mechanism for generating private keys from seed phrases. I took some time to talk to Earle Lowe, developer at Chia Network, in Keybase and he helped clear up the scope, so lets go through that here. Much thanks to Earle for a VERY patient explanation.

First things first, there is no security issue with the current implementation of the BLS signatures in Chia’s software from what I can tell. The keys generated from the seeds are still secure, and once a private key is generated in either implementation the public key would still verify signatures just fine. They are interchangeable in that way. The only difference is that the same set of 24 words would produce 2 different private keys (and hence all other derived keys, addresses etc). The reason Bram is saying that they won’t be changing anything is that there would be no technical benefit and the downside would be invalidating paper wallets or existing backed up seed phrases. If you type the words you got from a BLS Draft V2 generated wallet and typed them into a V4 system you would see a 0 balance and have no access to coins.

That being said, I think the reaction here was a little over the top, including by me, because that reads that they are going to have to go their own standard and the uphill battle that implies, or risk a hard fork that would invalidate every plot. That’s what those two messages from Bram and Gene indicate when taken together. But its not that big a deal. Not even close. From what I can tell a message signed by an HSM using the new standard will work on Chia still using the draft they are. And if they do need to implement the new keygen mechanism for some reason they could do it at the client side. There wouldn’t need to be a consensus change and you would still be able to farm with both key styles, even if there would be a user experience trade-off.

The actual change that is causing the issue itself, and preventing Chia from moving to the new standard, is the following change in the code. The old function:

Procedure:
   1. PRK = HKDF-Extract("BLS-SIG-KEYGEN-SALT-", IKM || I2OSP(0, 1))
   2. OKM = HKDF-Expand(PRK, key_info || I2OSP(L, 2), L)
   3. SK = OS2IP(OKM) mod r
   4. return SK

And the new keygen mechanism:

   Procedure:
   1. salt = "BLS-SIG-KEYGEN-SALT-"
   2. SK = 0
   3. while SK == 0:
   4.     salt = H(salt)
   5.     PRK = HKDF-Extract(salt, IKM || I2OSP(0, 1))
   6.     OKM = HKDF-Expand(PRK, key_info || I2OSP(L, 2), L)
   7.     SK = OS2IP(OKM) mod r
   8. return SK

   KeyGen is the RECOMMENDED way of generating secret keys, but its use
   is not required for compatibility, and implementations MAY use a
   different KeyGen procedure.  For security, such an alternative KeyGen
   procedure MUST output SK that is statistically close to uniformly
   random in the range 1 <= SK < r.

It’s very clear here that they do not need to update to the recommended keygen mechanism to maintain compatibility, so I do not know how much work it is going to be to enforce the old standard accross the ecosystem since they should both work together. Changing the salt on the BIP39 function (as Nucle does) also creates the same sort of incompatibility with words. Most wallets won’t be interchangeable, so Chia could easily have both, or support either mechanism easily. Again, it’s not a huge deal in the grand scheme of things.

I do think that they should strive to use the standard as finalized, when its finalized, just in order to be standards compliant (as annoying as that can be) and in order to do that it might be worth spending some real resources to take over the standard and match it to their implementation. Chia is by far the most widespread usage of BLS signatures right now, and changes here would have the largest effect so it is worth consideration that they should hold responsibility for it.

This is one of the problems with running draft cryptography. Earlier today I called it “hand rolled crypto” and its not that, its been written by very prominent cryptographers and its very impressive. But it isn’t a standard yet. No matter who assured Chia Network, or Bram personally that it was final, it isn’t actually final – hence draft. There might be even more changes, and the knee jerk reaction to not update is a bit of a red flag. There could be long term, far out issues caused by running permanently non-standard crypto. So I think its probably important to go the distance on making sure the current implementation of BLS is the one that makes into the final RFC, and to make sure that RFC gets filed.