-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Associated metadata for capsules #96
Comments
Hey @fjarri, this is a very cool idea :) This is basically a Schnorr signature of the metadata by Enrico. |
I've been thinking a bit about this, and although I don't see anything incorrect in your original approach, I think we can achieve the same thing following a more common construction, while keeping the spirit of your idea. In Umbral, we do something similar to create a validity check for capsules, that actually it's a mere Schnorr signature (but using the ephemeral private key labeled as
Umbral part (for backwards-compatibility):
Additional steps:
I think we can even perform the two checks at once to validate capsules with metadata more efficiently: |
...but what advantage are we gaining by using a Schnorr sig over a digest (HMAC-ish)? Just that Enrico can optionally reuse the private key as a branding mechanism? |
The problem with HMACs is that they are keyed with a secret key, and we want Ursulas (at the very least, but ideally, anyone) to be able to verify that a ciphertext is associated to a given metadata. How do we communicate such key to Ursulas (with the proper authentication & integrity assurance)? HMACs are fine for an end-to-end setting, but it's not clear to me how to extend them to work for an intermediate party that's not going to decrypt the ciphertext. |
Umbral is already using a Schnorr signature internally, so reusing the same cryptographic material to also associated metadata makes sense, while allowing certain backwards-compatibility. |
The following scheme can be used to associate reencryption conditions (or other metadata) with capsules:
Capsule
contains public pointsNow anyone having that proof and the capsule can verify that the proof was indeed created by the creator of the capsule by checking that$P_x + h * (P_r + P_u) = P_h$ . This is essentially the same approach that was used to attach metadata to capsule frags.
Note that this only establishes a one-way correspondence. Given a capsule one cannot know if any proofs were created for it; and Enrico can create several proofs for different metadata which all would pass the verification. Although this may not be important for the goal of attaching reencryption conditions.
The text was updated successfully, but these errors were encountered: