Proof of possession

[alinaT95]

Hello, guys.
Coud you please give a status for PopProve and PopVerify functions (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-3.3)? In review of BLS library (https://research.nccgroup.com/wp-content/uploads/2021/01/NCC_Group_EthereumFoundation_ETHF002_Report_2021-01-20_v1.0.pdf) this issue was reported. And it was claimed that the team gonna add it into Rust API. Your answer was: "The functions will be added to the library to complete the API. Currently this functionality is being performed by the application if needed." This answer is not clear for me. I suppose that you added work with proofs somewhere under the hood (in C). Because there is an option BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ that can be set in Rust. But it's unclear how it works. The size of serialized public key (that we gonna to transfer between Nodes) is the same both for BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ and BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_NUL modes. And this is really confusing. As I understand proof of possesion must be for example concatenated with public key. It's really unclear how one can get the proof for public key in Rust and work with it (for example: send to another Node for verification).
Could you give some more details how to handle proofs of possesion now?
Are you gonna to add PopProve and PopVerify funcs into your API in near future?

Thanks in advance. Best wishes.

[dot-asm]

And this is really confusing.

Yeah, count me in too:-) But let's get real for a moment. "PoP" is said to be PopProve, PopVerify and FastAggregateVerify. And specific DST, the domain separation tag. As for DST, it's the application's responsibility to pass a suitable one. And this is in all cases, not just PoP. In other words we are not talking about DST here. As for functions. One has to recognize that the draft is not exactly adequate as an API description. For example, the PopVerify description reads "Q = hash_pubkey_to_point(PK)" but it says nothing about PK format. Is it standard compressed? Uncompressed? Something else? It's effectively left to the application to decide. Hence blst has to leave the decision to application as well. But then what would the interface look like in practice? Make some assumptions and try to infer the application's intention? It's just too vague to be actionable. At the same time you have to recognize that at their core PopProve and PopVerify are indistinguishable from normal message sign and signature verification with the message being PK (or empty message with PK as augmentation parameter). This is what does "Currently this functionality is being performed by the application if needed" actually means. Now, one can still argue that there should be actual PopProve and PopVerify entry points. All right, but then the question becomes what would be sensible to do? Do you have suggestions? In form of actual function/method prototype.

Just in case, you say "proof of possession must be for example concatenated with public key." This sounds like a question about wire format. Keep in mind that wire formats, i.e. how actual packets are composed, is definitely outside blst scope. This is something for application to specify, or to follow some external specification.

[alinaT95]

Thank you very much for reply. I see now that I probably misunderstood how it worked. I thought that when we used DST=BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ mode it meant that we had signed messages and somewhere under the hood blst lib prepares proofs for public keys. But proofs were not available in rust. After your answer I see the picture like this. I need to sign messages and I want to have a protection against rogue attack (but messages augmentation is not good option for me).I have a situation when I sign one message by multiple keys. And I want to have optimal verification that will cost only 2 pairings. So I sign and verify my message using DST=BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_NUL_. And for creating/validating proofs I will use sign/verify function again but with DST=BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_POP. It's up to me in what format I will pass public key into sign function. And it's up to me in what format to transfer the proof to some Node. I can concatenate it with public key or not. It's my descision. Using different DST values for sign fuction will separate the domains for hash-to-curve function and then security requirement will be met.

[alinaT95]

Yes, I agree with you. How actual packets are composed, is definitely outside blst scope.

[alinaT95]

Have you seen by the way this library https://github.com/Chia-Network/bls-signatures#very-fast-verification-with-proof-of-possession-scheme? They were not reviewed yet. But they added PopVerify and PopProve to their API.

[mratsim]

Adding proof-of-possessions on top of BLST primitives is 3 lines of code for proving and verifying (Note: using compressed pubkey, you may make another design choice).

https://github.com/status-im/nim-blscurve/blob/02d4848d8444b12d6935aa57fbbb31988ba0a0b8/blscurve/bls_sig_min_pubkey.nim#L31-L74

[dot-asm]

... and somewhere under the hood blst lib prepares proofs for public keys.

No, blst is protocol- and application-agnostic bare-bones library. It might be helpful to view it as something that works with EC points and byte sequences, rather than keys and signatures. It's like musical instrument, you have to actually play it, as it doesn't know any tunes.

[dot-asm]

I'm not sure if we can make further progress here. The @mratsim's remark effectively confirms my point that "core PopProve and PopVerify are indistinguishable from normal message sign and signature verification with the message being PK." And with a specific DST. But since blst abstains from providing DST it makes less sense to provide designated entry points...