Skip to content

What is the purpose of sending verifying keys in ReencryptionRequest? #2812

@fjarri

Description

@fjarri

(making the discussion in Discord a little more permanent)

Currently, the structure of ReencryptionRequest is roughly as follows:

hrac
alice_verifying_key (avk)
publisher_verifying_key (pvk)
bob_verifying_key (bvk)
encrypt(hrac | kfrag | sign(hrac | kfrag, pvk))
    where kfrag = [kfrag_data | sign(kfrag_data, avk)]

Ursula has no side channels to obtain either of these verifying keys. The only side channel available is the blockchain, where she can check that the given HRAC is paid for. So, it seems that the only purpose of avk and pvk is for Bob to say "I can't decrypt the kfrag, but I know who signed it". Which is really just error checking. bvk is not really used at all.

So my question is: is there a security purpose for sending these verifying keys? What kind of attack is prevented by Ursula checking these signatures?

One important thing is that we do not use the HRAC structure (keccak(pvk | bvk | label)) at all. We could sign the whole request with bvk, and pass the label with the request, thus ensuring that the request is sent by the same person for whom the policy was issued - if that's something we want to do.

The reason for sending avk is even more unclear. Why would Ursula care if the kfrag is made by the person Bob claims it is? Is it just error-checking again?

Metadata

Metadata

Assignees

Labels

CryptographySignatures, Ciphers, Hashing Algorithims, EncryptionPREStrictly effects PREProtocolProtocol designquestionThis is a questionwontfixNon-issue or no intent for changes

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions