Recently, I presented our work on Let’s DOIT: Using Intel’s Extended HW/SW Contract for Secure Compilation of Crypto Code at CHES 2025 in the hot and humid Kuala Lumpur, Malaysia. The slides are available.

My colleague Vojta also presented exciting joint work, episode 2 of our reverse-engineering trilogy: ECTester: Reverse-engineering side-channel countermeasures of ECC implementations. The slides are available.

Few things for future reference on visiting conferences in Malaysia:

I recently attended CHES 2024 and presented a paper on pyecsca: Reverse engineering black-box elliptic curve cryptography via side-channel analysis. Check it out on our site. The slides are available.

While out in Halifax, we decided to enjoy Nova Scotia and went on a road trip. Some tips:

• Peggy’s cove: Kind of cool to cycle through, but not that amazing on its own. Expect lots of tourists.
• Hopewell rocks: Check the tides and the walk around is definitely worth it.
• Cape Breton Highlands: Nice hikes in very remote areas.

Recently we (me & Lukasz Chmielewski) gave a tutorial on pyecsca: Reverse-Engineering ECC implementations Using Side-Channel Analysis at the Summer School on real-world crypto and privacy 2024. You can find the tutorial on GitHub.

Today I came up with a clever solution for a dumb problem. When using multiprocessing or concurrent.futures in a Jupyter notebook one is generally limited to the fork start method. This is because the spawn and the forkserver methods require that the target function is defined in an importable module. If you are working with Jupyter notebooks the target function very likely resides in the notebook itself, which is not importable. So, how do we make it importable?

I recently attended CHES 2023 and presented a work-in-progress poster on pyecsca: Reverse-engineering elliptic curve cryptography implementations via side-channel analysis. Check it out below and also on GitHub.

I recently presented the paper “They’re not that hard to mitigate”: What Cryptographic Library Developers Think About Timing Attacks on Real World Crypto 2022 and IEEE Security & Privacy 2022. If you want to get more info on the paper including a pre-print and additional material, check out its page. The RWC slides are available as well as the IEEE S&P slides.

This year, we at the Crocs-Side-Scripting CTF team took part in the hxp CTF 2021 . It was another challenging CTF with hard challenges. This post contains our solutions to the four challenges we solved (Log 4 sanity check#, gipfel#, kipferl# and infinity# as well as a note on the solution to zipfel#. We came in at a respectable 34th place, which was an improvement from last years position. Hoping for top 20 next year!

Cryptographic code needs to be constant-time to not leak secrets via timing. Being constant-time is usually defined as:

• No branching on secret-dependent values.
• No memory access based on secret-dependent values.
• No secret-dependent values given to some variable time functions.

There are a few ways of testing or verifying that code is constant-time, for example using the tools I described in a previous post. In this post I looked at using Valgrind’s memcheck tool to test constant-timeness of primitives in the NSS cryptographic library.