It was actually broken, since we did overwrite the
out-coefficients instead of adding to them. Fixing this
again causes the same problems as described in the
inline comment, no matter which implementation we use.
In some very rare cases such as the polynom
1, -1, -1, 1, 1, -1, -1, 1, -1, -1, 1
the encryption->decryption cycle caused an incorrect result.
This wasn't reproducible for all polynomials, just for some.
Implementing the algorithm manually instead of using
the shortcut through
fmpz_poly_add(out, out, tmp_poly_msg);
fmpz_poly_mod_unsigned(out, ctx->q);
seems to have solved the issue.
Still unknown what happened there.
Use base64 (via glib) instead of plain char cast.
Remove ascii_to_poly() since it's unreliable (we don't
really know how many polynomials we will need
for a string).