[BLS-wg] Reverse BLS12-381

[Sean Bowe]

Hi,

BLS12-381 is so-named because it's from the Barreto–Lynn–Scott family
of curves. BLS signatures are so-named because it's a
Boneh–Lynn–Shacham signature scheme. It's usually the case that
pairing friendly curves have a short group encoding (G1) and a longer
group encoding (G2).

I would caution saying "swapping the curves" because it may indicate
you're changing the curve construction when you're actually just
changing the signature scheme. BLS12-381 doesn't define anything about
how you use them for BLS signature schemes, or which group you use for
the key or the signature.

I'm excited to see BLS signatures finally end up in a cryptocurrency.
Besides what group you use for the signature, it'll be important to
specify how you're hashing to that group (for BLS signatures). We've
been having discussions about this in my pairing library and in
another library. I'd like to see everyone using the same
well-specified technique to hash to the curve; hopefully this weekend
I'll have a spec fleshed out and we'll have test vectors for
inter-operability. It seems possible we could have this merged into
RELIC as well.

Sean

On Fri, Mar 16, 2018 at 4:41 PM, Bram Cohen via bls-wg
<bls-wg at lists.z.cash.foundation> wrote:
> Hey everybody. We at Chia are working on a new cryptocurrency and are
> planning on making BLS be the standard way all signatures are done in it
> because we like the noninteractive aggregation and unique signatures
> features.
>
> To that end, we're implementing them using the Relic library based on
> BLS12-381. Er, sort of. It turns out that BLS12-381 as defined has 96 byte
> public keys and 48 byte signatures, on the theory that usually public keys
> are published once and then used to sign many things. In cryptocurrencies
> it's the opposite, where public keys are published once and used to sign a
> fraction of one thing because signatures are aggregated. To that end we're
> swapping the curves around, so the public keys are 48 bytes and the
> signatures are 96 bytes.
>
> Our implementation is meant to be mostly api compatible with Bitcoin's
> Key.cpp except that we don't support non-compact signatures and don't have
> salt. Features we have or are working on include basic verification,
> aggregation, compact multisig, and SecureAllocator support, and maybe some
> more things I don't remember off the top of my head. Eventually we plan to
> swap out Relic for something constant time.
>
> -Bram