_decapsulate_original assumes that we have the "original" Capsule data (ie, point_eph_e and so on). Will we always?

[jMyles]

Is it possible that we'll only have _point_eph_e_prime and not _point_eph_e

[tuxxy]

I don't think so, these are components of the ciphertext of umbral. It'd be akin to deleting the nonce used in our ChaCha20-Poly1305 use in the DEM.

[jMyles]

So, it's not quite like deleting the nonce, right?

Are these original elements the content that Bob needs to provide to Ursula in order to collect CFrags?

Can we think of a scenario in which Bob wants to open the Capsule, but has disregarded the original elements?

It's great, in terms of code simplicity, if it's true that we'll always have these. What's your level of certainty? Do you want to hear from @cygnusv first?

[tuxxy]

It's my understanding that we will always have this with it.

[jMyles]

I'm not hearing you say you're absolutely certain. :-)

I pushed a little sketch there, just so we have one in the VCS history. I can scrub it back out (maybe replace it with a quick comment) if we become certain that we won't need it.

[cygnusv]

Are these original elements the content that Bob needs to provide to Ursula in order to collect CFrags?

Yes. And are also used for checking correctness. If Bob doesn't have them, he cannot be certain of the correctness of the re-encrypted ciphertext.

So, it's not quite like deleting the nonce, right?

Currently, no. Deleting the nonce destroys the possibility of decrypting, but here Bob can still decrypt, but he can't be certain of the correctness. Having said that, I have in mind a small modification in the way the DEM is integrated with the KEM that would make the original capsule components necessary for decryption. The goal is to increase the security of the scheme. In that scenario, it would be like deleting a nonce.

Can we think of a scenario in which Bob wants to open the Capsule, but has disregarded the original elements?

I don't think so. We could simply instruct Bob not to do that.
There is however another scenario that we are not considering and that poses a challenge here. Right now, Bob pushes the capsule to Ursula (therefore, Bob knows the capsule). An alternative would be that Ursula pulls the capsule from somewhere; in this case, Bob may or may not knows the original capsule. I think that in our system, the push model is easier and more natural, but I cannot ignore 100% the pull model.

[jMyles]

Right - the "animatronic Ursula".

OK, so I'll close this for now, scrub it out of the code, and leave a comment pointing to this Issue. Then, if we decide to add that feature, we'll resume discussions.

[jMyles]

@cygnusv: Consider, though, that we currently reconstruct a capsule (using from_bytes) without original data:

https://github.com/nucypher/pyUmbral/blob/master/tests/test_umbral.py#L153

In a real-world scenario, this will break, no?

What's really the point of providing a facility for serializing the reconstructed components? Just in case Bob wants to store it as ciphertext?

If it's that, don't we want to provide a public approach for him to store m-1 attached CFrags?