Feature Request: BLS Signature Support

[captain-kark]

Would it be possible to do something like add a C interface to https://github.com/Chia-Network/bls-signatures and release the capability to create BLS signatures in a firmware update?

This would be a great addition to the product. If you're able to devote time to it, I would be greatly appreciative, as there are next to none HSMs which boast BLS signature support, and a mature operating platform.

Thanks!

[kobigurk]

I'd like to second that direction! Though with another curve, or possibly both.

We're working on an embedded, constant-time version of BLS12-377 signing here: https://github.com/celo-org/bls-embedded/. We have code that works both on the thumb and armv7 instruction sets.

I think having BLS signature support for both BLS12-377 and BLS12-381 would be of great benefit to the community across many projects - some use them for consensus, some use them for application level security.

[a-dma]

Hi, what applications use/require this kind of signatures? Are they standardized or approved in any way? Or will they be? I'm not familiar with this signature scheme.

While I like the idea of supporting more applications, adding functionalities to the device itself is a long a complex procedure. And once a functionality is added, it is really hard to remove support for it.

I don't want to shoot down good ideas and suggestions, but it would have to be a really compelling case.

[kobigurk]

Standardization is underway: https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-00

BLS signatures have a compelling feature of non-interactive aggregation - signatures, either for the same message or different messages, can be aggregated by anyone into a single signature. In the case of the same message, it’s as efficient as verifying a single signature.

It’s being deployed in some places, e.g. to produce non-biasable randomness and in blockchain networks.

[a-dma]

Thanks for the reply.

I think this can be revisited when the standardization process has successfully ended and there is evidence of a widespread adoption.

[captain-kark]

@a-dma Do you have a procedure for distributing beta firmware in some other release channel, with reduced support and backwards compatibility guarantees? Also, would this imply that users need to acquire a similarly "beta" hardware device, with reduced protection from firmware update attacks? I'd be interested in such a program, if it exists.

I'll reopen the issue once the standardization process has successfully ended. At that time we can figure out what it would take to sufficiently prove widespread adoption.

[a-dma]

I'm sure that if and when this feature will be implemented and tested we can work something out.

I'll reopen the issue once the standardization process has successfully ended. At that time we can figure out what it would take to sufficiently prove widespread adoption.

Sounds like a plan to me.

[tyrion70]

Sounds like a good time to reopen this issue :) Celo is now live with BLS Signatures and we are dying to use our yubihsm's to sign. What would it take to reopen this issue?

[gaia]

Sounds like a good time to reopen this issue :) Celo is now live with BLS Signatures and we are dying to use our yubihsm's to sign. What would it take to reopen this issue?

+1. same for SKALE, SecretNetwork (Enigma) and Harmony.

[captain-kark]

I'll reopen this if:

• the IETF crypto forum, shepherded by @aamelnikov, places this BLS signatures RFC on a track for standardization before it expires in September.

• eth2.0 launches such that it commits to any deprecation strategy against the ethereum 1.0 standard

[tyrion70]

@captain-kark the RFC status makes sense, I’ll try to go after that, what does Eth2.0 have to do with it though? Could you elaborate a bit on that? Thanks!

[captain-kark]

Quoting @a-dma from earlier in the thread:

I think this can be revisited when the standardization process has successfully ended and there is evidence of a widespread adoption.

(emphasis mine)

The phrase "successfully ended" is a little vague, so if there's going to be more discussion about that, I would hope it would be balanced with the second clause that I've highlighted in bold, regarding widespread adoption.

Given that the projects cited in this issue asking for BLS signature support, derive significant portions of their platform from work happening in the ethereum project, I think it's fair to point to ethereum as the best indicator for adoption.

So, if the ethereum network begins depending on aggregate signatures for validators, etc., via BLS schemes, that would objectively represent de-facto widespread adoption. Personally, I think it's smarter to start now in anticipation of this technology being released, but then again I'm not a member of Yubico's board of directors so I can only advocate within the guidelines communicated to me by their contributors.

[cameroncooper]

Chia has launched their mainnet using BLS now, so does look like widespread adoption has happened. I've heard that the Ledger Nano X will have BLS support this summer as well.

[karalabe]

Ethereum here. Out of curiosity, did any BLS work end up on YubiKey products? The go-ethereum team is looking into how best to store and operate the beacon keys and I personally would prefer some hardware module. Though wondering if the HSM could support also specifying certain signing rules (e.g. disallow too frequent or even more specific ones); or whether we'd still need to rely on a dedicated machine if we want to create more complex rules?

[a-dma]

Hi,

neither YubiHSM nor YubiKey have support for those signature schemes.

The latest standardization effort that I can see is this which expired in 2021, please correct me if I'm wrong.

That document is still missing things like test vectors, an ASN.1 notation for the keys and a reference implementation (it only links to third-party ones and I don't know if one of those has become the de facto reference implementation).

It looks to me like there is not a lot of movement in that area unless, of course, I'm missing something.

[earonesty]

isnt this the signature scheme used by most of the "crypto" ecosystem, as well as most "identity based encryption" products? seems quite broadly used given the 200 billion dollar market

[uwuforever]

Also want to request this signature type, and Eth merges this week so at least one standard of it is being rolled out for good to a major production network.

But even if we don't agree about that being considered good enough a standard for YubiHSM to commit to as a core feature, I think it would still be worthwhile to consider as a paid upgrade feature or special edition - just considering a single use case, a single ETH2 BLS key is worth $55k USD now, there are 400,000 of them and growing, there are no true HSMs yet nor can they just use another algorithm,

[cameroncooper]

Ledger now has support for BLS in the Nano X with the new 2.1.0 firmware.

[uwuforever]

I will check that out. Although Ledger isn't really meant for unattended use (it requires manually approving each signature by pressing buttons on the device), so I still think something like this would be useful.

[pincente]

Though I would bump this considering the landscape has changed dramatically since 'Issue #66'.
There are now over 800K validators securing the Ethereum network, that's upwards of 25 million ETH staked to the tune of $42,533,500,000 USD at the time of writing.
Seems like the business case for adding this feature might be worth another look.

[guruhubb]

Does Yubico have BLS signature support? We need it for Zus servers, expect thousands of servers will use.