Skip to content

Back to the catalog

Optimized NEON Implementation of MAYO on Apple M1
eprint.iacr.orgpaper

Optimized NEON Implementation of MAYO on Apple M1

An IACR ePrint paper presenting an optimized ARMv8 NEON assembly implementation of MAYO Round 3 (one of NIST's post-quantum signature candidates) for Apple M1, generated to be byte-identical to upstream intrinsics but 2–2.6x faster for signing and verification across all four parameter sets. The authors also run a constant-time testing campaign with matched null runs and find that while linear-algebra operations are statistically indistinguishable from constant-time nulls, verification (on public data) exhibits a measurable key-fixed timing effect present in both their implementation and the upstream code.

TL;DR Faster, constant-time-tested ARM NEON implementation of the NIST PQC candidate MAYO on Apple M1, which also surfaces a residual timing side-channel in verification.
Document

What it is

Optimized ARMv8 NEON assembly implementation of MAYO Round 3 — the updated 2026 specification, which changed level-1 parameters and added a hash-derived linear term Λ to the verification equation, breaking compatibility with earlier optimized implementations. By Minwoo Lee, Minjoo Sim, Siwoo Eum, Hwajeong Seo. Targets Apple M1 (measured on one M1 Pro).

How it works

A code generator emits sixteen GF(16) kernels per parameter set as hand-tuned assembly, verified byte-identical to upstream NEON intrinsics output. Three specific optimizations drive the speedup:

  • A transposed constant-time echelon form that cuts cycles 55–70% versus the upstream approach.
  • An eight-way interleaved AES expansion of public matrices, running at 0.18 cycles/byte versus upstream's 0.43.
  • NEON-based expansion of the new Λ linear term; without this optimization, portable-C AES derivation of Λ consumes 10–22% of signing time and 18–37% of verification time.

Large kernels (excluding the Λ kernel) reach 86–96% of an operation-count speed model's prediction.

Preconditions / Affected

Applies to the MAYO Round 3 specification (August 2026 revision) specifically — implementations built against earlier MAYO rounds are not compatible due to the Λ term and level-1 parameter changes. Results are specific to Apple M1(/M1 Pro); portability to other ARMv8 cores is not addressed in the abstract.

What to do

Reported gains over upstream NEON code, as medians across seven function alignments: compact-key signing is 1.99–2.12x faster, verification 2.11–2.62x faster, consistent across all four MAYO parameter sets.

Caveats

The authors ran a constant-time campaign using matched null runs. Linear-algebra operations were statistically indistinguishable from constant-time nulls (at 25% power for a twofold dispersion). However, verification — despite operating only on public data — showed a measurable key-fixed timing effect, and this was present in the upstream implementation too, not just theirs. Separately, the MAYO₂ signature-test results diverged from this pattern, and the paper notes its signature test could not distinguish a public-data timing effect from a secret-dependent one. So the constant-time claim is qualified, not clean, and unresolved in the upstream code as well.

Technologies named here

  • Apple M1
  • MAYO upstream NEON implementation
  • Apple M1 Pro
  • Code generator for GF kernels
  • Eight-way interleaved AES expansion
  • ARMv8 NEON
  • MAYO
  • Constant-time measurement campaign
  • AES
  • ARM NEON

Techniques named here

  • Constant-time implementation
  • Transposed constant-time echelon form
  • NEON-based expansion of hash-derived linear term Λ
  • Timing side-channel analysis via matched null runs