From cecd5e10bbe894ad7fcd897577d83d0a58c46e45 Mon Sep 17 00:00:00 2001 From: "Matthias J. Kannwischer" Date: Thu, 9 May 2024 19:23:59 +0800 Subject: [PATCH] Update README.md Signed-off-by: Matthias J. Kannwischer --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index d4d37f6b8..c7b2eab68 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,8 @@ [//]: # (SPDX-License-Identifier: CC-BY-4.0) -**MLKEM-C-AArch64** is a collection of [MLKEM](https://doi.org/10.6028/NIST.FIPS.203.ipd) implementations for CPUs based on the Armv8-A and Armv9-A architectures. +**mlkem-c-aarch64** is a collection of [MLKEM](https://doi.org/10.6028/NIST.FIPS.203.ipd) implementations for CPUs based on the Armv8-A and Armv9-A architectures. -## Goals of MLKEM-C-AArch64 +## Goals of mlkem-c-aarch64 The primary goals of this project are as follows: - _Assurance:_ Clean code that's extensively tested and amenable for audit and verification @@ -13,16 +13,16 @@ There are tensions between these goals: - Optimal code is target-specific, but a large variety of CPU-specific implementations makes a library harder to both use and maintain. - Optimal code is complex (e.g. relying on handwritten assembly), impeding maintainenance and amenability for audit or verification. -In doubt, MLKEM-C-AArch64 chooses assurance and ease of use over performance: We only include implementations into MLKEM-C-AArch64 which are manually auditable or (ideally _and_) for which we see a path towards formal verification. We prefer assembly over intrinsics (for better control over register allocation and instruction scheduling), but all assembly should be as readable as possible and micro-optimization ideally deferred to automated tooling such as [SLOTHY](https://slothy-optimizer.github.io/slothy/). Ultimately, MLKEM-C-AArch64 strives for constant-time implementations for which the C-code is, at minimum, verified to be free of undefined behaviour, and where all assembly is functionally verified. +In doubt, **mlkem-c-aarch64** chooses assurance and ease of use over performance: We only include implementations into **mlkem-c-aarch64** which are manually auditable or (ideally _and_) for which we see a path towards formal verification. We prefer assembly over intrinsics (for better control over register allocation and instruction scheduling), but all assembly should be as readable as possible and micro-optimization ideally deferred to automated tooling such as [SLOTHY](https://slothy-optimizer.github.io/slothy/). Ultimately, **mlkem-c-aarch64** strives for constant-time implementations for which the C-code is, at minimum, verified to be free of undefined behaviour, and where all assembly is functionally verified. -MLKEM-C-AArch64 aims to provide a portfolio of implementations jointly providing competitive performance for most Armv8-A/Armv9-A microarchitectures. For some specific microarchitectures of particular interest, MLKEM-C-AArch64 may also provide CPU-specific implementations. Initially, our benchmarking platforms are: +**mlkem-c-aarch64** aims to provide a portfolio of implementations jointly providing competitive performance for most Armv8-A/Armv9-A microarchitectures. For some specific microarchitectures of particular interest, **mlkem-c-aarch64** may also provide CPU-specific implementations. Initially, our benchmarking platforms are: - Arm Cortex-A55 - Arm Cortex-A72 (as used in the Raspberry Pi4) - Arm Cortex-A76 (as used in the Raspberry Pi5) / Neoverse N1 (as used in AWS Graviton2/c6g instances) - Arm Neoverse V1 (as used in the AWS Graviton3/c7g instances) - Apple M1 -Please reach out to the MLKEM-C-AArch64 maintainers or open an issue if you would like to see benchmarking on other microarchitectures. +Please reach out to the **mlkem-c-aarch64** maintainers or open an issue if you would like to see benchmarking on other microarchitectures. ## Non-goals @@ -30,12 +30,12 @@ At this point, we do not provide implementations optimized for memory usage (cod ## Relation to MLKEM-C-Generic -Eventually, we aim to unify the (shared) C-part of the implementations provided by MLKEM-C-AArch64 with the implementations in [mlkem-c-generic](https://github.com/pq-code-package/mlkem-c-generic). Initially, however, we will allow some divergence, e.g. to explore interfaces to 2-/4-/8-way parallel Keccak implementations which are essential for high-performance implementations of MLKEM. +Eventually, we aim to unify the (shared) C-part of the implementations provided by **mlkem-c-aarch64** with the implementations in [mlkem-c-generic](https://github.com/pq-code-package/mlkem-c-generic). Initially, however, we will allow some divergence, e.g. to explore interfaces to 2-/4-/8-way parallel Keccak implementations which are essential for high-performance implementations of MLKEM. ## Current state -**MLKEM-C-AArch64** is currently a work in progress and we do not recommend relying on it at this point. +**mlkem-c-aarch64** is currently a work in progress and we do not recommend relying on it at this point. **WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS LIBRARY IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA.** Once we have the first stable version, this notice will be removed. @@ -43,11 +43,11 @@ The current code is compatible with the [`standard` branch of the official MLKEM ## Call for contributors -We are actively seeking contributors who can help us build **MLKEM-C-AArch64**. +We are actively seeking contributors who can help us build **mlkem-c-aarch64**. If you are interested, please contact us, or volunteer for any of the open issues. ## Call for potential consumers -If you are a potential consumer of **MLKEM-C-AArch64**, please reach out to us. -We're interested in hearing the way you are considering using **MLKEM-C-AArch64** and could benefit from additional features. +If you are a potential consumer of **mlkem-c-aarch64**, please reach out to us. +We're interested in hearing the way you are considering using **mlkem-c-aarch64** and could benefit from additional features. If you have specific feature requests, please open an issue.