separate the sources into dedicated directory, fix doc generation

[tomato42]

for the documentation generation to work, the code needs to work as a package and be importable, and the package needs to have a valid name (kyber-py won't work), so put all of the sources into the src/kyber directory. Upside: clear separation between shipping code and tests. Also, because everything is in single module, it won't pollute python namespace.

also change it to use relative imports so that any future refactoring is easier (and they're recommended anyway)

[GiacomoPope]

Thanks for doing this work. The only thing I'm not sure about is calling the package "kyber" but I don't have a great idea about what to do. It's annoying to have to think about the future here as Kyber will be an antiquated name at some point. Maybe mlkem_py, ml_kem_py, py_mlkem or even kyber_py... can't decide and I'm not super happy with any of them

[GiacomoPope]

Also I think I prefer the absolute rather than relative paths to functions but if relative is the standard then I guess I can accept this.

[tomato42]

Thanks for doing this work. The only thing I'm not sure about is calling the package "kyber" but I don't have a great idea about what to do. It's annoying to have to think about the future here as Kyber will be an antiquated name at some point. Maybe mlkem_py, ml_kem_py, py_mlkem or even kyber_py... can't decide and I'm not super happy with any of them

I still see plenty of code that refers to AES as Rijndael... 🙂 and kyber definitely rolls of the tongue better than ML-KEM, unlike Rijndael vs AES...

The thing is, that the package name in PyPI is kyber-py, so the principle of least surprise is that the top level module name should have at least kyber in it. But if you'd prefer kyber_py I can change to that... with relative imports that will be fairly easy 😉

[GiacomoPope]

Yeah ok let's do kyber_py for the package name. I don't think that we should "package" this properly until the final spec is out but it doesn't hurt to pick a name now.

[tomato42]

Well, I'd prefer it as a package for integrating into tlslite-ng...

[GiacomoPope]

Sure I appreciate that. Originally I was very against this being an importable package as I wanted to dissuade people from using it for cryptography but let's see what state the code is in after a little more work.

[GiacomoPope]

Thanks for changing the name.

Could we also tweak the examples in the README so the imports are correct for users?

>>> from ml_kem import ML_KEM128
>>> ek, dk = ML_KEM128.keygen()
>>> key, ct = ML_KEM128.encaps(ek)
>>> _key = ML_KEM128.decaps(ct, dk)
>>> assert key == _key

to something like:

>>> from kyber_py.ml_kem import ML_KEM128
>>> ek, dk = ML_KEM128.keygen()
>>> key, ct = ML_KEM128.encaps(ek)
>>> _key = ML_KEM128.decaps(ct, dk)
>>> assert key == _key

[tomato42]

@GiacomoPope also docs needed fixing, I've added them to CI now so it will be clear if/when they get broken again :)