Most of ASCON Suite is written in C and provides high-level API's for encryption, hashing, and other modes. The main exception is the core ASCON permutation which is implemented in C or assembly code depending on the platform.

The backend permutation implementations are located in the src/core directory. Each backend provides a "state and permutation" (SnP) interface to the rest of the library and user applications. See the Permutation page for more information on using the SnP API directly in your own code.

With the assembly code backends, the core permutation is implemented in assembly code but some of the SnP utility functions may still be in C. Only some of the backends have masked versions for side channel protection at present.

Backend	Language	Word Representation	Masked Version?	Platforms
c32	C	Sliced 32-bit	Yes	Default plain C implementation for 32-bit systems
c64	C	Host 64-bit	Yes	Default plain C implementation for 64-bit systems
armv6	ASM	Sliced 32-bit		ARMv6, e.g. Raspberry Pi 3 running the 32-bit Raspberry Pi OS
armv6m	ASM	Sliced 32-bit		ARM Cortex M0 and M0+
armv7m	ASM	Sliced 32-bit		ARM Cortex M3, M4, and M7
armv7a	ASM	Sliced 32-bit		ARM Cortex A7 (uses armv7m backend)
armv8m	ASM	Sliced 32-bit		ARM Cortex M33 (uses armv7m backend)
armv8a-64	ASM	Host 64-bit		64-bit ARMv8-A; e.g. Raspberry Pi 4 running the 64-bit Raspberry Pi OS
avr5	ASM	8-bit	2 or 3 shares only	AVR5 and higher; e.g. ATmega328P (Arduino Uno), ATmega2560 (Arduino Mega 2560), etc. The masked version only supports 2 or 3 shares at present.
i386	ASM	Sliced 32-bit		32-bit x86 systems (i386/i486/i586/i686)
m68k	ASM	Sliced 32-bit		32-bit 680x0 and ColdFire systems
riscv32e	ASM	Sliced 32-bit		32-bit RISC-V systems, RV32E base integer instruction set
riscv32i	ASM	Sliced 32-bit		32-bit RISC-V systems, RV32I base integer instruction set
riscv64i	ASM	Host 64-bit		64-bit RISC-V systems, RV64I base integer instruction set
x86-64	ASM	Host 64-bit	Yes	64-bit x86-64 systems
xtensa	ASM	Host 64-bit		Xtensa, as used on ESP32 and ESP8266 modules, using funnel shifts for 64-bit word rotations

The "armv7m" backend can run unmodified on many higher-spec'ed 32-bit ARM processors. In fact, the "armv7a" and "armv8m" backends are just the "armv7m" backend compiled for a different architecture. This may change in the future if there are advantages in creating specific optimised backends for ARMv7-A and ARMv8-M.

If the "armv7m" backend does not work on an unsupported 32-bit ARM processor, then it is possible that "armv6" or "armv6m" will work instead (the "armv6" backend is faster). Performance may not be as good as writing a tailored backend for the new processor.

The specific permutation implementation is selected by the include file ascon-select-backend.h which defines the macro ASCON_BACKEND_XYZ to select the XYZ backend. You may need to modify the #ifdef's in this file if your preferred backend is not recognised.

The ascon-select-backend.h file may also define one of the following extra macros to select the SnP utility implementation to use:

ASCON_BACKEND_DIRECT_XOR - Bytes can be directly XOR'ed with the ASCON state to absorb data, and directly copied out to squeeze data. This can only be used on platforms that use the big-endian word order of the ASCON standard. Most backends use host byte order instead to avoid the overhead of converting back and forth between little-endian and big-endian.
ASCON_BACKEND_SLICED32 - The backend uses the 32-bit bit-sliced method to represent the state. 64-bit words in the ASCON state are split into two 32-bit halves. The even and odd bits are placed into different words. This representation usually works best on 32-bit systems.
ASCON_BACKEND_SLICED64 - The backend uses 64-bit words but they are stored in host byte order instead of the canonical big-endian byte order of the ASCON specification. This representation usually works best on 64-bit systems.
ASCON_BACKEND_INIT - The backend has a ascon_backend_init() function that must be called to initialize the permutation as the initialization is more complex than simply clearing the state to zeroes.
ASCON_BACKEND_FREE - The backend has a ascon_backend_free() function that must be called to free the permutation and destroy sensitive information in registers and on the stack.

The encryption, hashing, and other modes that are implemented in the library have direct knowledge of the underlying word representation of the selected permutation. This allows them to avoid the SnP function call overhead in some cases. User applications do not have access to this information. This keeps the public API simple and makes it easier to enforce binary compatibilty across library versions.

Most user applications have no need for the SnP API because they can use the relevant encryption or hashing API from the library directly. The public SnP API is provided just in case an application has a specific requirement that isn't met by the standard modes. If the new mode is truly useful, then it may be incorporated directly into a future version of the library.

If ascon-select-backend.h cannot locate an assembly code implementation, it will fall back to ascon-c64.c on recognised 64-bit platforms. Otherwise it will fall back to ascon-c32.c.

The assembly code implementations were generated using the programs under the tools directory. These tools make it easier to audit the implementation for correctness and to apply incremental optimisations over time.

The generator tools can also be reused across similar platforms; for example, the armv6 backend is generated by the same tool as the armv7m backend because other than the ARM-vs-thumb instruction encoding issue, the code is almost identical. The armv7m backend took quite some time to evolve into its current state. The armv6 backend was done in a few hours.

If you wish to submit a new backend implementation, please consider writing a generator tool for your platform rather than writing the assembly code by hand. Or modify one of the existing tools that is close enough to almost work.

In the future it may be the case that CPU manufacturers will provide accelerated ASCON encryption and hashing modes in silicon. Depending upon how the silicon is implemented, this may involve writing a new permutation backend or it may involve completely replacing the high-level modes themselves.

Existing accelerators for AES and SHA-256 tend to operate at the mode level rather than the block level. So it is likely that future ASCON accelerators will too. This library can in theory support complete mode replacment by #ifdef'ing out the C version of the mode and providing an alternative implementation. We'll cross that bridge when we come to it.