Do we need to carry around UmbralParameters?

[fjarri]

At the moment it only contains one field, u, which only depends on the curve selection. Calculating it takes ~10% of a single point-scalar multiplication (for k256, 8us vs 100us), so in all places where it is used in can be safely created on the spot without a significant performance loss.

[tuxxy]

Rather than calculate on the spot, it might be better to simply let this be a static var somewhere at the top of pre.rs or something.

Another option is to serialize the point and store the bytes as a const, but I don't like that as much since the parameter seed acts as a "nothing up my sleeve number".

[fjarri]

From the discussion: calculate it in a macro when the crate is built.

[fjarri]

Something I just realized - in PyUmbral we don't actually bundle parameters with capsules. So there is a precedent.

---

Bundling gives us easy compatibility if we decide to change u (or even g). For example, if someone manages to find log_g(u) for the current values. But note that we still do not encode the curve itself in the parameters in any way, so the compatibility is limited. Is there even a standard serialization for curve types?

The main downside is that there is more data to come with the capsule (2 points = 66 bytes), with the rest of the capsule taking 98 bytes. How important that is is uncertain. KeyFrags (especially with the proofs) will take significantly more space.

Another consideration could be the time of generating the parameters (mainly, the value of u). Currently it is very quick - about 8us, which amounts to a few point multiplications. If we were to calculate it on the spot, it probably would not be too noticeable (although that needs to be supported by performance tests).

If we decide to have a default Parameters values, it cannot currently be created as const or static due to Rust limitations (none of the necessary functions from the backend are const; why you need that for static variables is beyond me, but perhaps that requirement will be relaxed in the future). One could do it in a build script, but that requires duplicating some of the code from the main library (since it cannot be imported), duplicating the curve choice, and is in general pretty messy.

[fjarri]

Another consideration: deriving u from g makes sense if, and only if Parameters are bundled with serialized umbral objects. In that case serialized Parameters can include only the value of g, and if the pair g, u becomes compromised (someone finds the logarithm), we can dynamically change it by creating capsules with a different g. Of course, it won't help if SHA256 itself (or our application of it) is compromised.

Although if we decide to include both g and u in the serialization (to trade object size for performance), deriving u from g loses sense again.

[fjarri]

(starting to hate this issue)

g needs to coincide with the point used for secret/private keys, which is fixed in the backend (and probably shouldn't be touched, because it's better to preserve compatibility with the standard keys). So u has no reason depending on g whatsoever.

[cygnusv]

Let's do it as you suggest (i.e. u = H('some string'), not depending on g). My motivation was more interesting in a more generic setting, but often in cryptographic engineering, generality is a liability rather than a plus, and I think in the end it's pretty clear that we're aiming for a "1 curve, 1 hash, 1 AEAD" implementation.

In that case, can we drop the parameters from capsules and other objects? The parameters will be static, if it's a problem for Rust to compute u, can we just hard-code it?

[fjarri]

Ok, hiding Parameters for good - in #41