Delete old classes and replace their use with new math features

[JanBobolz]

We want to get rid of

• PrimeFieldPolynomial (replace with PolynomialRing and its elements) and SecureRandomGenerator (automatically becomes unused after removing PrimeFieldPolynomial)
• LagrangeUtil feels like it should be replaced by use of PolynomialRing, too. Maybe have to look closer into its uses (but I cannot imagine its uses cannot be replaced by de.upb.crypto.math.structures.polynomial.PolynomialRing#getPoly(Map<? extends RingElement,? extends RingElement>)).
• de/upb/crypto/craco/interaction (can just be deleted, has no use)
• de.upb.crypto.craco.abe.interfaces.Triple can go.
• de.upb.crypto.craco.kem.asym.elgamal.ElgamalKEM#computeNonceHash can essentially be replaced by HashIntoZn (though this has less of a priority since it's an implementation detail and does not affect API)

[rheitjoh]

PrimeFieldPolynomial was used in AbstractIBEFuzzySW05 and DistributedABECPWat11Setup in such a way that resulted in me adding some more methods to the API of PolynomialRing to offer similar functionality as previously. Specifially:

• a method to create random polynomials of a specific degree with non-zero coefficients
• a method to set a specific coefficient of a given polynomial (not allowed to increase degree with this)

[JanBobolz]

a method to set a specific coefficient of a given polynomial (not allowed to increase degree with this)

Please don't make Polynomial mutable. Whatever code needs the functionality to compute a polynomial coefficient-for-coefficient should do this on their own terms (e.g., instantiate an array of coefficients).
If I remember correctly, the two users of this "setCoefficient" functionality are just doing polynomial interpolation (I may be wrong here), so why can't they just use the getPoly method mentioned above?

[rheitjoh]

The two users just instantiate a random polynomial of non-zero coefficients with specific degree and then set the 0-th coefficient to a specific value. I certainly can have that done manually.

[rheitjoh]

I would ike to move WatersHash to Math since it already contains hash functions. Then we could either move LagrangeUtil with it or move the LagrangeUtil.computeCoefficient() method directly into WatersHash. Its only used there and it is just used to compute the output of a lagrange polynomial (so I don't think it can be replaced by use of PolynomialRing).

Also, ByteArrayQueue is unused and could therefore be deleted.

[JanBobolz]

WatersHash: go for it.
LagrangeUtil: wait... What? Why does the Waters hash function need any Lagrange stuff? What does this class think the Waters hash function is? In my mind, it's https://eprint.iacr.org/2011/270 page 2, "Instantiations", i.e.

@feidens am I not seeing something from the good ol' project group days here? 🤔
https://github.com/upbcuk/upb.crypto.craco/blob/f886aee644f650e4c2f91da789e40c4e87f0add9/src/main/java/de/upb/crypto/craco/common/WatersHash.java

[rheitjoh]

So seems like the Waters Hash we implement in this case is the one from page 26 in this paper. Since the waters hash is only used in a couple of our predicate encryption schemes, it seems sensible to move it to the Predenc project.

The LagrangeUtil stuff is also used to interpolate polynomials in DistributedABECPWat11 and our Fuzzy IBE.
So we still need it in some form that can be used there. One could try and refactor its use a bit such that the whole interpolation via group elements is factored into its own method and then move that to Math. The PolynomialRing methods are not applicable here since we do not have the polynomial evaluations available.

[feidens]

https://github.com/upbcuk/upb.crypto.craco/blob/f886aee644f650e4c2f91da789e40c4e87f0add9/src/main/java/de/upb/crypto/craco/common/WatersHash.java can we put the paper reference to this class respectively to the method that evolves out of this discussion.

[rheitjoh]

Okay, I moved WatersHash to the Predenc project, moved LagrangeUtil to Math and added a interpolateInTheExponent method to it. The former also includes a ref to the paper now.

The latter is only used for WatersHash right now.
The Fuzzy IBE cannot use it since the interpolation is done on the left side of a pairing for better efficiency and the distributed ABE would also get slower by using it since it does multliple interpolations at the same time and otherwise would need to recompute the same lagrange coefficient multiple times.

[rheitjoh]

All the issues except refactoring de.upb.crypto.craco.kem.asym.elgamal.ElgamalKEM#computeNonceHash have been addressed by #33.