nucypher/ferveo

Instead of the symmetric ciphertext, pass its hash when creating/checking the auth_tag

cygnusv opened this issue · 5 comments

cygnusv commented

One of the steps of the creating and checking the Ciphertext authentication tag is to compute a G2 hash element as follows (in pseudocode):

   tag = hash_to_G2(commitment_U, sym_ciphertext, aad)

However, this forces that anyone performing ciphertext validation (e.g. Ursula) must pass the symmetric ciphertext, which can be very inefficient. Instead, let's just pass a hash of the ciphertext:

   tag = hash_to_G2(commitment_U, sym_ciphertext_hash, aad)

With this change, the consumer would never have to include the bulk of the symmetric ciphertext in the decryption request, but only it's hash, which even has a known size.

cygnusv commented

This allows for 2 formats:

  • "Raw" ferveo ciphertext format: commitment, auth_tag, symmetric_ctxt
  • "Thin" ferveo ciphertext format (for decryption request): commitment, auth_tag, symmetric_ctxt_digest (known size: G1 + G2 + sha256 length)

Unsure on how to expose this through the API yet. Thoughts?

jMyles commented

This seems plausible on its face, but what then does the other side the API look like in your mind?

If a user (or our depending libraries) adopt the 'thin' version, what do they do with the bulk ciphertext once they have the hash?

cygnusv commented

My 2 cents:

  • The thin format (which we can view as a return of the Capsule) requires to handle the symmetric ciphertext separately in some cases. But still, for user-facing interactions, Bob will handle MessageKits, which we define as follows:

MessageKit = Thin ferveo ciphertext + symmetric ciphertext + ACP (see nucypher/nucypher#3187)

  • In decryption requests, however, the full MessageKit is not required, only the thin ciphertext (a.k.a, the Capsule) and the ACP. The TS & python client, should be able to take what they need from the MessageKit to construct decryption requests, without creating a burden on the creator/consumer side. We can also expose API methods to extract MessageKit components if needed, but I'd prefer if these are only exposed as an advanced usage (the notion of Capsule + Ciphertext in PRE was confusing).
  • Overall process is that (1) the creator takes a message, a public key (alternatively, a ritual ID if they're blockchainy) and an ACP JSON file, and produces a MessageKit, and (2) the consumer takes a MessageKit and requests decryption to Ursulas (via Porter in most cases). See nucypher/taco-web#166 (comment)
  • The thin format should be defined in a bytes format, with nucypher-core.
jMyles commented

Perfect.

But to make the process iterative, let's start by hacking together the format up above until we find something we like, and then later codifying it in nucypher-core.

derekpierre commented

Perfect.

But to make the process iterative, let's start by hacking together the format up above until we find something we like, and then later codifying it in nucypher-core.

This is being explored in nucypher/nucypher#3194

Still WIP, but thus far: