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

[cygnusv]

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]

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]

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]

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 Alter PRE-adapted tDec API design for CBD-DKG taco-web#166 (comment)
• The thin format should be defined in a bytes format, with nucypher-core.

[jMyles]

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]

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:

• Need ferveo encrypt(...) to return the dem_ciphertext and kem_ciphertext - https://github.com/nucypher/nucypher/pull/3194/files#diff-c20d5c9104edf072fb7ea92061c93b65b00103bbe323370bbabcb7990d71dc61R1481. These should be available separately since only the kem_ciphertext needs to be inlcuded in the ThresholdDecryptionRequest sent to nodes.
• Need ferveo decrypt_with_shared_secret(...) to take both dem_ciphertext and kem_ciphertext - https://github.com/nucypher/nucypher/pull/3194/files#diff-c20d5c9104edf072fb7ea92061c93b65b00103bbe323370bbabcb7990d71dc61R774
• Updates to nucypher-core entities: see core.py - namely AccessControlPolicy, ThresholdMesageKit, and ThresholdDecryptionRequest - https://github.com/nucypher/nucypher/pull/3194/files#diff-b73a831f5a5adcd87ae48916fdff3f3c15dbb139e1cb5f95c849032c66c68957. EncryptedThresholdDecryptionRequest can be ignored - it was only changed to make the new ThresholdDecryptionRequest work seamlessly.