Skip to content
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

Add header and payload to Ciphertext bindings #154

Closed
cygnusv opened this issue Aug 11, 2023 · 7 comments
Closed

Add header and payload to Ciphertext bindings #154

cygnusv opened this issue Aug 11, 2023 · 7 comments
Assignees

Comments

@cygnusv
Copy link
Member

cygnusv commented Aug 11, 2023

To facilitate the creation of TDec Requests after the changes introduced by #149, we need a set of helper functions to facilitate getting the necessary information, i.e., commitment U, authentication tag W and hash of the symmetric ciphertext. Tentatively, let's call this the header, and for the bulk of the symmetric ciphertext, let's call it the payload. This is what just something that we need above the ferveo level, so that's why I'm suggesting doing this in the bindings

@piotr-roslaniec
Copy link

piotr-roslaniec commented Aug 14, 2023

Just to get on the same page:

// No changes
pub struct Ciphertext<E: Pairing> {
    // U
    pub commitment: E::G1Affine,
    // W
    pub auth_tag: E::G2Affine,
    // V
    pub ciphertext: Vec<u8>,
}

impl<E: Pairing> Ciphertext<E> {
	// ...
	pub fn header(&self) -> CiphertextHeader<E> { ... }
	pub fn payload(&self) -> CiphertextPayload
}

pub struct CiphertextHeader<E: Pairing> {
    // U
    pub commitment: E::G1Affine,
    // W
    pub auth_tag: E::G2Affine,
    // sha256(V)
    // Note: Preferably a static array, either [0u8; 32] or GenericArray<U32>
    pub ciphertext_hash: Vec<u8>, 
}

pub type CiphertextPayload = Vec<u8>;

Bindings are just wrapping & exposing these methods and structures.

Not sure what other changes are required at this point (e.g. what consumes these new structures, etc.), but IMHO we just need to zero in on the data structures, and the rest should fall into place.

@cygnusv
Copy link
Member Author

cygnusv commented Aug 14, 2023

Yes, I think that sounds fine, but let's see what @derekpierre thinks, since he asked for this to facilitate the work in the nucypher-core and nucypher layers. The point here is to add this just as a helper function for nucypher-core consumption, without impacting anything else on the Ferveo side.

IMHO we just need to zero in on the data structures

Can you elaborate on this?

@piotr-roslaniec
Copy link

piotr-roslaniec commented Aug 14, 2023

Can you elaborate on this?

I was just trying to say that even though I'm not familiar with the upstream of this issue, it seems to me like implementing these structures will require a minor refactor, and it should be fairly easy.

@piotr-roslaniec
Copy link

piotr-roslaniec commented Aug 14, 2023

Drafted updated Ciphertext API here: #155

@derekpierre
Copy link
Member

@piotr-roslaniec I think you are on the same page.

The crux of the issue is this: #149 (comment).

From the python-side it could be ugly for when decryption requests need to be made, to take the Ciphertext and then process it to hash the underlying ciphertext, then pass the auth_tag, commitment, and hash of the ciphertext to then include all of those in the request, and then Ursula to take each of those and pass it to some ferveo library function as 3 separate parameters.

What would be more ideal is if the auth_tag, commitment, and hash of the ciphertext is encompassed in one object - eg. Header which python can use to create the decryption request, and then Ursula passes it to a ferveo library function call for deriving the decryption share eg. `derive_decryption_share(header: Header, ...).

Obtaining that Header object can be a struct member of Ciphertext or a method in Ciphertext that returns it...just something that doesn't involve python requiring such deep level understanding of the ferveo cryptosystem.

Using auth_tag, commitment, hash of ciphertext etc. in the python-side causes so much of the underlying ferveo crypto to leak out instead of just using a single ferveo object that represents all of that information internally that we don't have to care about it.

Similar issue would be for nucypher-ts - at lease the decryption request part.

@piotr-roslaniec
Copy link

piotr-roslaniec commented Aug 16, 2023

check_ciphertext_validity method implements one of the verification methods outlined by the original Ferveo implementation. It requires the availability of the ciphertext when creating a decryption share.

Does it make sense to compute the "tag hash" (hash_g2 in the code example) on the encrypter side and contribute it to CiphertextHeader? Does it break the 4.4.2 validity check?

@cygnusv @derekpierre

Edit: Resolved by Discord conversation with @derekpierre - The prerequisites for this change have already been addressed here: https://github.com/nucypher/ferveo/pull/149/files#diff-77fd8e16ac649ad31c2c194cc79b5f867795266417d190b9d372609b92d7e2b6R35.

@cygnusv
Copy link
Member Author

cygnusv commented Sep 6, 2023

Closed by #155

@cygnusv cygnusv closed this as completed Sep 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Completed
Development

No branches or pull requests

3 participants