My team, NCC Group's Cryptography Services, and I, together with colleagues in Hardware and Embedded Systems and AI/ML, conducted a series of security assessments involving selected aspects of Google's Private AI Compute in the cloud.

Read the public overview report on NCC Group's research web site.

https://www.nccgroup.com/research-blog/public-report-google-private-ai-compute-review/

#cryptography #ai #research

I am very happy to report that physical copies of our Tamarin book are now available from Springer Nature. Order your hardcopy here:
https://link.springer.com/book/9783031909351

or read the PDF and the accompanying files for free here:
https://tamarin-prover.com/book/index.html

big thanks to my co-authors David Basin, Jannik Dreier, and Ralf Sasse!

2025.23/24 Vibe codified - Rakudo Weekly News

https://programming.dev/post/32311744

It is not well-documented, but it turns out that if you try to run crypto benchmark code on a STM32F407 ("discovery") board (with an ARM Cortex M4 CPU) with instructions in SRAM (instead of Flash), then you get extra delays, unless you set SYSCFG_MEMRMP accordingly. After a week-end of dabbling, I can now run my benchmarks (for Falcon/FN-DSA) at 168 MHz with no wait states or cache issues. Details here: https://github.com/pornin/c-fn-dsa/tree/main/bench_cm4

(As a side-note, I have done some more assembly optimization work, so signing cost is now 19.7 mcycles at n=512, down from 22.0 previously.)

This week I implemented the velusqrt algorithms for the rust library im working on: https://github.com/GiacomoPope/isogeny_rs

Good news is that it works generally and is pretty fast (~100s of microseconds for an isogeny in CSIDH compared to 10s of milliseconds in Sage) but it's definitely not standing up to the state of the art. There's a few reasons for this:

1. I am not using the scaled remainder tree for multipoint evaluation. A proper implementation of this needs a handful of specialised polynomial arithmetic functions to compute the low, inverse and middle elements of the product of two polynomials f and g.

2. I probably have made some silly mistakes in Rust itself and I'm wasting time with clones and allocation when I could be borrowing more or using scratch buffers

3. My estimates about inversion costs and multiplications through sets is slightly off and I should invert less and use projective things more. This is a little harder to guesstimate in a general setting without picking a precise prime.

If anyone wants to collaborate on optimising this please let me know. I’m sure there’s loads I could be doing better!

This week I had some research time and developed a rust library for isogeny based-cryptography. The main feature is that I have an implementation of SQIsign following the NIST round 2 spec with 4.5ms verification time using pure Rust (no assembly for my finite field arithmetic).

There's still a lot to improve, clean up, document etc, but I thought some people might be interested: https://github.com/GiacomoPope/isogeny_rs

Super interested to collaborate to expand this library further and to improve performance and readability of the code.

New paper on computing pairings using cubical arithmetic with applications to isogeny based cryptography.

https://eprint.iacr.org/2025/672

Summary:

If you are careful with the projective factors of a point (X : Z) after computing scalar multiplication then you can compute the Tate pairing e_n(P, Q) directly from the values P, [n]P and [n]P + Q using only the x-only Montgomery ladder. The Tate pairing naturally also gives the Weil pairing. The end result is more efficient and easier to implement pairings for any curve with a Montgomery model.

SageMath implementation for E/Fq and Rust implementation for E/Fp^2 available too

http://github.com/GiacomoPope/cubical-pairings