RP2350 hacking challenge 2: into extra time
Roughly three months ago, we launched our second RP2350 hacking challenge, this time focusing on the side-channel analysis of our new SCA-hardened (side-channel analysis–hardened) AES library.
We’ve had some good chats with a number of teams and individuals working on this challenge, and it looks like our new AES library is thus far unvanquished, but we hear that progress is being made and a bit of extra time might provide ample opportunity to ruin our day (yay…). You’ll no doubt be glad to hear that we’re therefore extending the submission deadline for this challenge to midnight (UK time) on 31 December 2025. The RP2350 Hacking Challenge 2 page is the place to go for full details of the challenge: happy hacking!
AE-yes?
AES is a very popular and important block cipher encryption standard. It has been widely used for over twenty years now.
As part of our recent 2.2.0 Pico SDK release, we added a useful new tool that allows folks developing designs with RP235x to AES-encrypt their software and data stored in flash, and securely decrypt into on-chip SRAM at boot (RP2350 has lots of on-chip SRAM, and we mainly boot from external QSPI flash chips). This new self-decrypting binary support is very important to customers who wish to protect their software and application data from reverse engineering, decompiling, flash readout, or modification.
Many AES implementations (both software and hardware) are susceptible to side-channel attacks. Most of these attacks involve recording and carefully analysing many hundreds of thousands (or millions) of traces that detail various goings-on in the chip while it is decrypting AES-encrypted data. Typically, these are time-series measurements of power consumption and/or electromagnetic emissions. Using these measurements, it is often possible to learn or spot data that is being leaked, and this data in turn can be used to reduce the effective length of the AES key, often to the point where it’s feasible to brute-force the rest of the key. Once you have that, you can cause all sorts of mischief.
To help protect RP2350 against this, we worked with some talented folks to harden and test our custom AES implementation against these side-channel attacks. You can read more about this hardening work here.
Take a look at the RP2350 Hacking Challenge 2 page to find out more about our current, newly extended challenge, and watch this space for an update on the results once the new deadline has passed.
4 comments
Jump to the comment form
Raspberry Pi Staff Ashley Whittaker
We should add that you will also be ruining the day of our friends at hextree.io who helped us with this challenge. Two birds.
Tim Cliffe
On the subject of technological security, do recent developments in the EU, regarding dumping Microsoft in favour of openCode (https://www.theregister.com/2025/10/31/international_criminal_court_ditches_office/) and Linux distributions (https://www.slashgear.com/1888658/microsoft-office-alternative-denmark-libreoffice-linux-why-move-important-explained/), present opportunities for Raspberry Pi?
ED
Because of the end-of-year date, I’m sure most people will correctly(??) understand the deadline to mean: before the new year, so at the end of 31 Dec. And in this case, the very few people for who this matters have probably been in direct contact. But in general, “midnight” is just the worst as a deadline! *Usually* midnight means the start of the next day, not the end of the previous day, see e.g. https://en.wikipedia.org/wiki/Midnight#Start_and_end_of_day
So this always leads to confusion. A common solution is to phrase it as: 31 Dec at 23:59:59.
Tim Cliffe
Dear ED;
There was a time, in what is now known as the UK, when the the day changed at midday not midnight; even more confusion :-)