redfast00

Did you check for rotational and mirror symmetry? As in, are the 12 unique sudokus just the same one, rotated in 4 ways, and mirrored along the x or y axis?

From the datasheet, I see that there is a Bitscrambler peripheral that seems to be very similar in flexibility to the Raspberry Pi Pico's PIO:

> Since bitwise operations can be relatively CPU-intensive and DMA is designed specifically to offload such work from the CPU, ESP32-S31 integrates two dedicated peripherals called BitScramblers. These modules are designed to transform data formats during transfers between memory and peripherals. One BitScrambler handles memory-to-peripheral (or memory-to-memory) transfers, while the other is dedicated to peripheral-to-memory transfers. While BitScramblers can handle the bitwise operations mentioned earlier, they are in fact flexible, programmable state machines capable of performing more advanced transformations as well.

Here's hoping that it's as useful as the Pi Pico's PIO

In my opinion, the author understates how good AES-GCM-SIV is:

> The solution they designed is described in that linked paper: AES-GCM-SIV, which is able to tolerate some number of nonce collisions, but under a weaker notion of security that is only really applicable to that use-case (where the data being encrypted is itself random).

AES-GCM breaks catastrophically if you reuse a nonce; but the only thing that happens if you reuse a nonce with AES-GCM-SIV for two messages is that an attacker can see if the messages are equal (since AES-GCM-SIV is a deterministic algorithm, this is pretty much unavoidable). So yes, "weaker notion of security", but still applicable to a lot more than just that use-case. I wonder why AES-GCM-SIV is not used more, since it's so developer-friendly and misuse resistant.

Please contact me via email (at the bottom of the blog post)

As part of the NLNet grant, I will build an affordable Faraday cage; I'll post the BOM, assembly process and a test report in a separate blog post.

Oops, my bad, copy-pasted it incorrectly; fixed now

You first need to find ground. You can do this by visual inspection (a bit less risky), or by using your multimeter in continuity mode across external metal parts (for example the outside of the USB port)/negative pin of the power supply. Then, you can use a logic analyzer to find the serial TX pin. The RX pin is usually pretty close, and might be pulled up through a resistor to VCC.

This is raw memory, so the concept of malloc/free does not really exist: the OS will just overwrite the data.

I think (not entirely sure) that the kernel gets relocated to a more or less fixed address in memory anyway, this won't affect your runtime experience.

Try to identify a serial port on the PCB, connect a serial adaptor to it (careful to get the pins and voltage right!) and take it from there

(Edit: or google the PCB board markings, maybe somebody already did this)

Mainly by looking at what addresses the original bootloader loads them into. The addresses don't matter too much, as long as you load them into valid memory, since for most you pass a reference to them anyway in later steps.