BLS pink research

Research
4

I have studied this proposal. I was mostly interested in the construction in Section 3, as it seems to be the basic building block for the other constructions at the document.

Be aware that I had to make some speculations, since not everything in the document is carefully explained.

Here are my thoughts:

  1. Section 3 introduces BLS sigs to MW. I suppose that the purpose is for kernel aggregation – it is not mentioned explicitly in this section, but the last paragraph of Section 2 states that the following discusses “a potential modification … that does allow for full kernel aggregation”.

  2. While not said explicitly, I suppose that all the involved signatures use the BLS signature scheme (except where written otherwise). In particular the proof of knowledge of the kernel excess (outputs - inputs) [more precisely the value DeltaC] is by BLS.

Note that BLS aggregation is vulnerable to the rogue key attack, as explained in Section 2. To avoid this attack one could prove the knowledge of the private key (excess value).

  1. The latter seems to be the main idea in the proposed construction: “that involves an explicit signature to s that could be individually verified against the known public key”.
    It seems that instead of proving the knowledge of the excess value, the idea is to prove only part of it, which is the knowledge of the value s.
    This is already somewhat troubling, since it is stressed that the signature verification does not involve the new public key P=sG.
    Moreover, each output is a pair (C,P), but since P is not used in the first part of the verification, it is not clear what avoids one from taking an output (C,P) and changing it to (D,Q)=(C+P-Q,Q) for any Q.
    In this case DeltaC doesn’t change – it is still C+P-C’-P’ – so a signature for this kernel excess is already given. However now the adversary could prove the knowledge of the private key for the associated public key Q (the adversary eliminates the need to prove s).
    It may be that this can be avoided by the range proof – similar to the original need in range proofs – but this hasn’t been directly addressed in the document.

  2. The proposal does not specify what is the message being signed with the excess value.
    Aggregating the public keys (kernel excess), and not only the signatures, requires that all messages should be the same.

To summarise, it seems to me that the public key was introduced in order to prove the knowledge of the excess value (thus prevent the rough key attack against BLS aggregation), but I am not sure that it indeed achieves it (nevertheless the kernel excess signature already proves this). It may be that this construction was tailored specifically for the other uses that are presented in the document.

1 Like