What's a better error message in decapsulate_reencrypted than "generic umbral error"?

[jMyles]

I don't exactly understand what is being asserted here.

Perhaps, "This capsule doesn't appear to have been made for this public key" ?

[jMyles]

This error seems to be raised if not enough cFrags are present to open the Capsule.

However, currently the assertion requires original Alice components to check. @cygnusv: Is there a way to check without those?

[cygnusv]

That check is ensuring that the reconstructed capsule comes from the original capsule, so by definition, there is no way to check that without the original components.

There are many possible problems that may make this check to fail, but from the cryptographic point of view, we don't want to give detailed information of the error in order to avoid potential attacks. The reason is that there are many attacks out there exploiting the different possible error messages to infer secret information (e.g., private keys). An example (not applicable here), is padding oracle attacks

[cygnusv]

Having said that, this error message could be something like you said: "This capsule doesn't appear to have been made for this public key" or perhaps "This capsule doesn't appear to be openable with your private key"

[tuxxy]

I propose: "Failed to decrypt with the provided private key"

[jMyles]

Poking around, I seem to be able to generate this error in two ways:

1. Trying to decap with the wrong private key.
2. Trying to decap without enough cFrags.

Is there a way to naively (ie, without injecting the value of m) distinguish between these problems? Worse to give a generic error message is to give an incorrect one.

[jMyles]

There are many possible problems that may make this check to fail, but from the cryptographic point of view, we don't want to give detailed information of the error in order to avoid potential attacks. The reason is that there are many attacks out there exploiting the different possible error messages to infer secret information (e.g., private keys)

Well, if something is knowable in the scope of this function, then it is already in the purview of an attacker who has direct witness over its execution. Sure, we don't want to encourage users to spread detailed error information in a public way (as with any application), but I don't think there's any harm in this function failing in such a way that discriminates between the various possibilities, is there?

[cygnusv]

Is there a way to naively (ie, without injecting the value of m) distinguish between these problems?

I think there is not (and there shouldn't be).

Well, if something is knowable in the scope of this function, then it is already in the purview of an attacker who has direct witness over its execution.

Yes, that's true, but that's not the target type of adversary for this measure. We are dealing here with the ones that have black-box access (e.g., remote access).

[jMyles]

Yes, that's true, but that's not the target type of adversary for this measure. We are dealing here with the ones that have black-box access (e.g., remote access).

Exactly, so there's no harm in the function raising different errors for these different conditions.

[KPrasch]

This now an exception class umbral.GenericUmbralError. Still could use a better message.

[tuxxy]

I think we can go ahead and close this now. @jMyles @KPrasch @cygnusv

[KPrasch]

At the moment, there is no message at all: https://github.com/nucypher/pyUmbral/blob/master/umbral/pre.py#L476

Edit: line moved: https://github.com/nucypher/pyUmbral/blob/master/umbral/pre.py#L440

[KPrasch]

Do we intend to leave the message blank here? https://github.com/nucypher/pyUmbral/blob/master/umbral/pre.py#L440