Rename mlkem-c-aarch64 to mlkem-native

[mkannwischer]

@hanno-becker and I would like to broaden the scope of MLKEM-C-AArch64 from Arm-focused to application-core focused, notably including support for x86_64. We believe that lack of support for x86_64 is an adoption barrier, as it forces consuming repositories to maintain two copies of largely but not entirely matching C code. In contrast, having a single C base as close as possible to mlkem-c-generic, and a common C<->ASM/Native interface that's implemented by AArch64 and x86_64 backends (and whatever comes in the future), will be easier to work with.

Obviosuly, we do need a new name, and we'd like to propose mlkem-native (as-in "native code", capturing both ASM and intrinsics). Let us know if there are other suggestions.

We do not quite know what the process of a repository name change is, but by posting it here, we wanted to give everyone the opportunity to comment and we'll raise it during the next TSC meeting.

[planetf1]

I don't see any technical issues with a repo change, indeed github adds a redirect to the old name, so even forks should continue working. We'd need to rename in UI & also update our access management tools.

We can discuss the name change today. I agree with your premise around lack of x86-64 support being an impediment broadly for pqcp. We have mlkem-c-generic that isn't yet onboard, though I still think there may be a place for a 'reference' implementation, alongside a more optimized/curated version which you have here?

[hanno-becker]

Thank you @planetf1 for your reply. Let's discuss in the next TSC meeting.

We have mlkem-c-generic that isn't yet onboard, though I still think there may be a place for a 'reference' implementation, alongside a more optimized/curated version which you have here?

I am no longer sure about that. We have kept mlkem-native very close to the reference implementation already, plus started added CBMC proofs for the C code. I feel mlkem-native could (should?) become the replacement of the reference implementation in PQCP. This way we could focus our energy on that repository, and also reduce customer confusion as to what repository to pick.

[mkannwischer]

Note that mlkem-c-aarch64/mlkem-native does have C code for all the functions implemented in assembly, so it is possible to turn off assembly and use it for any platform.
So for actual integration in libraries, I agree with @hanno-becker that there may not be a need for a dedicated reference implementation within PQCP. Maintaining it in one place is much easier.

[planetf1]

Thanks @hanno-becker @mkannwischer, that's great news. This proposal moves forward several issues - having a native C implementation, ensuring more commonality between implementation, having an implementation available for liboqs to use as well as being aligned with the goal of having higher assurance implementations.

A good topic for discussion on Thursday, but it sounds an excellent solution to me

[hanno-becker]

(cc @planetf1) In the 24-10-24 TSC meeting, we agreed that mlkem-c-generic should discontinue and for mlkem-c-aarch64 to take its place, while also offering backends for optimized implementations on specific architectures.

The question of naming, however, was not settled. The current candidate for the renaming remains mlkem-native, but we'd be happy about any other suggestions. Any ideas?

[planetf1]

@hanno-becker I think it's one of the best ..

Possibly: mlkem-generic, mlkem-base, mlkem-universal, mlkem-standard

Just to throw some ideas out there that I don't think are as good: mlkem-default, mklem-basic, mlkem-essential, mlkem-real, mlkem-primary, mlkem-pluggable, mlkem-simple, mlkem-inclusive

I think we have to drop the '-c-' (as you did) since it's also going to contain assembler, so I see why you went with the suggestion you did.

[hanno-becker]

mlkem-ref is another option emphasizing proximity to the official Kyber ref implementation -- maybe this repo will take on that role over time.

[hanno-becker]

mlkem-app as in "application cores" (server, mobile, desktop), contrasting mlkem-embedded

[mkannwischer]

I don't like app - that term is too overloaded.
We could step away from things that make sense? Possibly there is a suitable Star Wars term?

Maybe related: Does anyone know where the name donna in curve25519-donna comes from?

[planetf1]

@mkannwischer Obviously need to be careful with any trademarks.. a few thoughts (that stick to using normal words and only have a loose association)

mlkem-saber
mlkem-gem
mlkem-light
mlkem-multifaceted
mlkem-celestial

[hanno-becker]

I overall remain in favour of mlkem-native.

[mkannwischer]

Thanks @planetf1 for the suggestions!

I agree with @hanno-becker - mlkem-native remains the best option so far.