Review use of tiny_poly in tests

[teor2345]

I think we should not test an encryption scheme using tiny parameters. It is not secure when instantiated like that, an even correctness doesn't hold and weird things happen. We should not worry making it pass the unit test because a corresponding situation doesn't happen for real parameters. Can we stop using tiny parameters for YASHE tests?

_Originally posted by @emmorais in https://github.com/Inversed-Tech/eyelid/pull/82#discussion_r1603866109_

Currently, the tiny polynomial helps us:

• diagnose test failures by providing a small polynomial to compare
• find edge cases that are less likely with larger polynomials
• make sure our code doesn't hard-code dependencies on Fq79
• operations can easily be compared using Sage

Tasks:

• [ ] Try to find an alternative small polynomial that works for YASHE encryption and decryption
• [ ] Run all tests with TestRes = IrisBits to increase coverage

[teor2345]

We tried a few different YASHE configs with the tiny polynomial, but we couldn't get encryption and decryption to work: https://github.com/Inversed-Tech/eyelid/pull/82/files#diff-2b7586ffb2a536b051ce13c1d4bf638ef6f9d5a74f091a12a6c0c2583def6b76R97-R112

Instead, we used the full resolution polynomial as an alternative config in commit 9426102 (#82)

This is good for code coverage, but will make diagnosing encryption or decryption failures tricky due to the large number of terms in the polynomial.

We might be able to define a polynomial with roughly double the modulus and double the terms. If we do, we should increase the error delta to 0.4, so that each term is likely to have zero or one values. This also means increasing the key delta and T.

[teor2345]

In practice we’re using tiny where it works, and using medium where it doesn’t.