[BLS-wg] Reverse BLS12-381

[Sean Bowe]

> Right, we're swapping the curves from *a* implementation which was used to give reference numbers but not actually misusing the primitive at all.

I think it's totally fine if you want to use G1 for public keys, but
I'm still confused about the language you're using to describe
BLS12-381.

The title of this thread ("Reverse BLS12-381") and "It turns out that
BLS12-381 as defined has 96 byte public keys and 48 byte signatures"
are both inaccurate. BLS12-381 doesn't define what a public key is or
what a signature is because it's a curve construction, not a signature
scheme.

I just want to make sure others aren't confused because these are
easily confusable names. Carry on!

Sean

On Fri, Mar 16, 2018 at 6:03 PM, Bram Cohen <bram at chia.net> wrote:
> On Fri, Mar 16, 2018 at 4:22 PM, Sean Bowe <sean at z.cash> wrote:
>>
>>
>> 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.
>
>
> Right, we're swapping the curves from *a* implementation which was used to
> give reference numbers but not actually misusing the primitive at all.
>
>>
>> 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.
>
>
> Dan Boneh just sent us a construction which allows for a speedup on
> aggregated signatures of a single value, which we'll be implementing for
> performance. It isn't standardized because it's new but we plan to have
> everything we're working on be published and reviewed and ideally
> standardized.
>