Add conversion functions Z.to_bytes and Z.of_bytes

[xavierleroy]

Converting between big integers and byte sequences is important e.g. for cryptosystems based on number theory. The existing Z.to_bits and Z.of_bits conversion functions are useful but a bit limited: they use little-endian representation while big-endian is more common for crypto protocols, and there's no way to control the size of the output of Z.to_bits, while many protocols fix the length in advance.

This PR implements Z.to_bytes and Z.of_bytes conversion functions that let the user choose endianness, the size of the output, and whether signed numbers should be accommodated (using two's complement representation). The functions are modeled after the int.to_bytes and int.from_bytes Python standard library functions.

[antoinemine]

That looks great, thanks!

In Python, byteorder seems to be optional and defaults to big-endian.
I like that, if not specified, the length is automatically set. Would it be useful to export length computation to the user in a dedicated function (e.g., if the length needs to be checked or rounded by the user before conversion)?

Also, happy New Year!

[xavierleroy]

Thanks for the feedback, and happy New Year !

In Python, byteorder seems to be optional and defaults to big-endian.

Right. It's true that big-endian seems much more common esp. in cryptographic protocols, so I thought making it the default. But then it clashes a bit with the use of little-endian in Z.to_bits. Also, being explicit about endianness is good documentation in user code.

I like that, if not specified, the length is automatically set.

Yes, I think it's useful as a canonical representation of a Z.t as a string. Z.to_bits is not canonical because it pads differently on 32-bit architectures and 64-bit architectures. (Although this is something we could fix independently.)

Would it be useful to export length computation to the user in a dedicated function (e.g., if the length needs to be checked or rounded by the user before conversion)?

I don't feel a clear need at this point. The use cases I ran into while playing with cryptography use fixed lengths and you're guaranteed that the encoded integer will fit this length (because it's taken modulo q for appropriate q and length).