support loading and retrieving kyber 512/768/1024 keys

[alexanderkjall]

This is a companion PR to randombit/botan#3546 and uses the functions exposed in the ffi interface from there.

One design thought that I had was that the functions right now take [u8] as arguments, instead of the precise key sizes like [u8; 800]. This makes it a runtime error if you provide the wrong size of a buffer to the function, instead of a compile time error. But I thought it's more important to follow the style of the other functions.

[randombit]

This makes it a runtime error if you provide the wrong size of a buffer to the function, instead of a compile time error.

Wait this seems wrong though because the FFI functions expect a fixed size array and we do not check the length. So passing the wrong slice here will cause an out of bounds read.

[alexanderkjall]

I think the wrong size is caught by the check here: https://github.com/randombit/botan/pull/3546/files#diff-a410fa358793a5877ce21830f0e8986bf9d8fe021a694e3389b67d1c440d6d2bR920

I couldn't manage to produce a segfault when I tested this, only different forms of errors.

It's comparable to how the buffer handling works in x25519 keys, see: https://github.com/randombit/botan/blob/master/src/lib/ffi/ffi_pkey_algs.cpp#L831 and https://github.com/randombit/botan-rs/blob/master/botan/src/pubkey.rs#L85

It's maybe a bit fragile to only do the check on the C/C++ side, but on the other hand it feels like the correct side to do it on if it's only going to be done on one side.

But I'll rebuild this now anyway.

[randombit]

@alexanderkjall Sorry for the delay here. We'll have to bump the minimum required version with botan3 feature to 3.1 to make this work, but that seems fine. As a first step can you rebase against master and force push? CI has changed quite a bit so I'd like to make sure things are looking good there.

[alexanderkjall]

No problem, I never expected this to be a fast merge.

I'll get to do a rebase but am on vacation right now.

Don't we need to have botan3 be released, and then also wait for it be packaged in the important distributions before we merge this?

[randombit]

Botan 3.1 is already out, but you're right that I don't want to have us in a continual ratchet of only supporting the latest version. I think the real fix is #109 where the botan-sys crate detects the version and exports a cargo flag that indicates the version, and then the botan crate can adapt without us having to use botan3.1, botan3.2, ... feature flags which would grow cumbersome very quickly.

[alexanderkjall]

Sorry for the very long delay here, live got in the way.

Is there any other change you want me to do other than rebase and force push?