Summing up, in my personal opinion: XMPP > Signal > Matrix > Anything else. The situation is not optimal:

• Signal is centralized.
• Matrix is pretty much centralized, and has a shady ecosystem.
• XMPP has non-uniform user experience, things might not work, adoption is scarce, cryptography is less good than Signal’s. Is there really no better alternative in 2025?

Simplex This is pretty new and I haven’t tested it in depth yet, but I’ve read great reviews about it. I will keep this updated. Stay tuned! UPDATE 2024-08-18 after a preliminary investigation, there are a few things that do not convince me about Simplex. It’s not a hard nope for now, but I cannot endorse it yet. Be patient and stay tuned for a followup.

Lastly, how about P2P IM? I don’t know of many (Briar?), feel free to suggest one if you care, but the problem with P2P systems for IM is that, in general, users can only communicate if they are online at the same time. Which might be acceptable in some use cases, but it’s not a solution that will cover most users’ needs.

I hope this was useful to you, or at least clarified a few doubts. Just don’t use shitty IM, especially if owned by some psychopathic rich individual, it is bad for you and humanity!

(Jan 1st, 2025) Announcement: I’m starting a new collaboration with Horizen Labs! New year, new life! After exactly 6 years of service, yesterday saw the end of my employment at Kudelski Security. Effective immediately, I am joining Horizen Labs in the role of Senior Cryptography Researcher.

I want first to remark how grateful I am to Kudelski Security and my amazing ex-colleagues for these awesome 6 years, it was really a good ride! But I felt it was time for a change, and I found in Horizen Labs a great opportunity to expand my knowledge in cryptography. In my new role, I will help to research, develop and optimize zero-knowledge proof systems such as STARKs and SNARKs. This is an immensely complex field which has always fascinated me, and finally I have the opportunity to dig deep into it! I find the topic of ZKP interesting regardless of the cryptocurrency applications, as I believe many privacy-friendly technologies can benefit from these schemes, but I also liked the pragmatic mindset and the good atmosphere at my new team. I am looking forward to tackling new challenges!

For the record: I am not relocating, I will still be based in Zurich, but I will visit Milan occasionally, where Horizen Labs has an office where most of the tech people are.

(Aug 28th, 2024) A retrospective rant about (some of) DEF CON VillagesFinally I have some time to report about my recent trip to the US for attending Black Hat and DEF CON. I also went on an AMAZING (but short) solo road adventure after DEF CON, which was probably the best part of the trip, but I don’t want to talk about that. I want to talk about DEF CON, and especially (some of) the villages. The reader shall pardon the unusual writing style that I will adopt for this post, definitely unprofessional and more akin to a rant from an internet troll than to an objective and rational argument. Just for the lulz.

First of all, it must be stressed that I’m no DEF CON veteran, in fact my first DEF CON was only last year; I am therefore in no position to assess the "trend" or compare this year’s event to the "history" of this amazing convention. I am also in no position to comment about this year’s badge drama, because I don’t think I have enough information about that to form myself an opinion. But, as a single data point, this year’s DEF CON felt to me "less cool" than last year’s. Maybe the novelty factor, or (more likely) the new venue. Having to drive through the Loop to reach the venue on "public transport" from the Strip? Brrr... cringe. Also, how the f*** is it possible that all the 2XL t-shirts are sold out during the first 23 minutes from open doors? I mean, I don’t want to imply anything with this but... you are selling merch at DEF CON... you should know your average customer... May I kindly suggest you to have the BULK of your merch in 2XL and 3XL size and only have a smaller amount of the rest?

But let’s talk about something else: the villages. From my understanding, DEF CON villages became more and more prominent over the last years, as a "more inclusive" way to create community. Which is cool, and I’m sure that there are *some* villages that are tremendously fun and interesting. Unfortunately, that did not apply to the two villages I was mainly interested in.

One of these two villages, let’s call it the "sci-fi village", is pure crap. No joke. But I was aware of it, because I visited it last year already, so I had no big expectations. To be fair, due to the very nature of the "sci-fi village", it’s a bit difficult to have activities/talks that are both engaging AND technically interesting, and moreover, this year I didn’t spend too much time there, so it’s definitely possible that the situation improved, or is going to improve in the future.

The second village, instead, let’s call it the "super-security village", or SSV. I missed it last year, but I’ve heard good stories about it, so I decided I need to show up and, dunno... get involved? Get "included"? Offer volunteering help for next year’s edition maybe, or even submit a talk or propose something cool. For sure I should bring there my Shufflecake stickers! I mean, this is DEF CON, it’s STICKER-CON! Everyone LOVES stickers at DEF CON, and I’m sure the SSV will be happy to have Shufflecake stickers around!

Full of trepidation, I wear my Shufflecake t-shirt and follow the map to the location of this village inside the enormous venue. The first impression is already... disappointing. The SSV has been allocated one of the largest village spaces: there is a stage, desks for the organizers, a lot of tables around, even some large and well-made custom props. And it is... almost empty. Nobody on stage, maybe 10 people all around, most of them look like organizers. The tables are dark and empty.

I put on my most genuine smile and approach the desks of the organizers, who... ignore me. They keep chatting among themselves with an aura of boredom, or keep staring at their phones and laptops. I keep smiling and nodding around with no success. After some time I gather my courage: "Ah-ehm... hello?". A guy maybe half my age slowly raises his head to me, his look is the cosmic emptiness of enthusiasm and interest. "Hi, my name is Tommaso, I’m new to this village but I also love super-security! So, I was wondering... what do you people do here, what is there to see?".

The guy picks up a napkin from a pile. Oh wait, that’s not a napkin, it’s actually a printed leaflet folded in half? He hands it over to me. "You see, this is the SSV, we do super-security. You know, this and this. And this is the program". The program looks... amateurish? To put it nicely. "Intro to super-security". "How to make your phone super-secure". "Surprise talk by a university professor". WTF? And the program is... sparse, there are, like, only two talks this morning.

I must try hard not to be snobbish, because I would hate a snob myself. So I keep smiling and say "Ah cool, you know, I’m a super-security practitioner myself. Actually, may I leave some of these stickers around? Have you ever heard about Shufflecake? No? TrueCrypt? Neither? OK, this is... an open-source software to... encrypt your disk and... it’s developed by a friend of mine and myself and... we published a paper at CCS last year and... I thought..." (my words fumble as I see the expression of boredom on the guy turning first to confusion and then to skepticism) "I thought... this would be perfect for the SSV... maybe some people are interested... this is the website... what do you think?".

"Weeeell" says the guy, crossing his arms on the chest and leaning back while pulling his chair away from me. "You know, I cannot... we cannot... endorse third-party software. Understand?".

STICKER-CON, YOU ASS, THIS IS STICKER-CON! IS THIS THE WAY TO WELCOME ME?

"Uh... Oooook... I see... May I... leave the stickers on the tables around here then?". The guy pulls a nervous smirk. "Umph! Well, I’m not POLICING THE TABLES... YET."

I am OUTRAGED and I leave the place. I have never been so coldly welcomed at a private party to which I was not invited. I decide to have a look at their website.

• Outdated ("past talks" 2020).
• Full of JavaScript that would make RMS scream in fear.
• A Google Calendar form for showing the program.
• All organizers listed as their Twitter handles only.
• "Store" section.
• "Subscribe to our YouTube and Twitch channels so you don’t miss out!" WHAT IN THE DEPTHS OF HELL AM I SEEING HERE?

I resolve to write this ranting blog post and I keep enjoying my DEF CON. But the day after, I change my mind: I should not be an asshole just because I met a weird guy, maybe he was not in a good mood, or jet-lagged, or under drugs, or whatever. I cannot judge the SSV just by my interaction with ONE of their organizers - provided he was an organizer indeed, and not a random volunteer. So I decide to try again, with renewed enthusiasm!

I go to the SSV again and the situation is like the day before. But I don’t see yesterday’s guy, so maybe I will have better luck today! I approach again the desks of the organizers, and this time I am welcomed by another 20-something guy who seems actually friendly and full of enthusiasm!

"Hey, welcome to the SSV! Check our program and if you have any questions just ask!" Oh yes, this is going well. "Hi, I’m Tommaso and, this is my first time at this village but I am a super-security practitioner myself and..." "OOOHHH SERIOUSLY? Then you absolutely have to talk with [random name], he’s also an expert in super-security, you know... HE STUDIED MATH AT THE UNIVERSITY!" and he made his eyes as big as golf balls while saying that. "Uhhh... sure, I’d be happy to talk with him... but for now I just wanted to understand, what kind of talks or activities are you people interested in? You know, I was considering contributing next year". "Ah, in this case you MUST ABSOLUTELY talk with [name2] who’s main organizer, come with me, I’ll introduce you".

The guy walks me along the tables, while I am wondering what is exactly the meaning of "introducing me" since I barely said a word about myself. I have the feeling that the guy just wants to get rid of me quickly, but whatever. He points me to another human being sitting there doing something at the computer and then says "Hey, this guy here wants to talk about talks, he’s a super-security practitioner." and then he leaves. The other human being looks at me surprised and says "Oh, hello there!". But before we could even start a conversation, a bunch of other people arrives, interrupts us and (ignoring me) start to talk with the organizer, who quickly apologizes to me "I’ll be around later, excuse me" and leaves with the other bunch of people.

I can’t even. Are all zoomers like this nowadays? I feel... old.

Humiliated, I go back to the friendly guy. "Hey, how did it go?". "Well... busy times I guess... I’ll talk later with [name2]. But may I ask you... Are you one of the organizers?". "Oh no" the guy says, "I’m only a volunteer, I help to run things!". "OK" I say, "and how did you get involved?". I’m asking this to the guy to understand how this social group was formed. Because, so far, to me it looks like these are a bunch of stoned "internet friends" who somehow managed to scam DEF CON into conceding them their "private corner" (either that or they are Dogecoin millionnaires and paid for the space themselves), and are not really interested in "including" other people at all.

"Well, I didn’t know anyone at first, but then I joined their chat and I got to know people. The chat is basically the main thing where the community lives, we all know each other there. YOU SHOULD JOIN OUR DISCORD AS WELL IF YOU WANT TO CONTRIBUTE!"

D-I-S-C-O-R-D? I mean, you are the SUPER-SECURE VILLAGE and you have your community ON DISCORD? Why not FACEBOOK???

And this was the straw that broke the camel’s back, so I changed my mind AGAIN and I decided to write this post.

I conclude with two thoughts. The first one is a story of my time back during my PhD in Darmstadt. Every time we would go out for lunch, we would cross a part of the residential neighborhood, and we would pass in front of a super-typical "Quartiersstube", one of countless many in German towns. I had never been into one, so I asked some of my German colleagues to go there. "Are you kidding?" they replied. "You just... cannot go inside there... that’s not for you... I would not go there myself! You must be... born and raised here, in ’da ’hood... or a friend of a friend...". I did not understand. It was a public venue after all. So, one day, I decided to go there alone and order a beer. Let me just say that I got my beer, but the way I felt at the SSV was more or less the same I felt inside that pub.

The second thought is, what price is reasonable to pay for "inclusiveness" at a venue like DEF CON? And by "inclusiveness" I do not mean stuff like, welcoming everyone regardless of sexual identity, skin color, etc, that’s something I give for granted and, hopefully, we will be able to give for granted more and more in the future. What I mean is that, at the end of the day, it’s a hacker conference, people pay to go there and expect a certain level of technical involvement. It’s fine to have a "intro to XYZ" session for n00bs, but if more than half of your program is like that, then I question you belonging to this "hacker conference".

In any case, this is just a very un-serious rant about my personal, subjective experience. I am sure I was just unlucky and next year it will be much better. Would you accept a technical talk submission by a humble super-security practitioner? Please welcome me better next time, I have expectations.

But I’m still not joining your Discord.

(May 30th, 2024) How I Put my Foot in my Mouth with Whit Diffie at Eurocrypt 2024Yesterday night I was attending the rump session at Eurocrypt 2024 in Zurich. Whit Diffie (yes, that Whit Diffie) was there and, during one of the breaks, he very kindly allowed people to queue up in line to take pictures with him. For a second I considered how kind of unfair it was, having a multitude of super-world-famous cryptographers all there at the venue, and still people only wanted to take pictures with him, but, I mean, Whit Diffie is Whit Diffie after all! So I lined up as well, and when my turn came I asked if I could have a picture next to him. "It would be a honor", I said, and he smiled and nodded back. Then I took place next to him, while another person was taking the picture with a phone. And then I told him something.

What I intended to say was something on the lines of:

I’ve been in this field for so long, and yet I never managed to take a picture with you before, thank you so much!

What I did say instead, because I was distracted by someone talking at me and then I slipped my tongue, was:

I’ve been in this field for so long!

He laughed at me and said "Yeah, I’ve been for longer!".

And then spaghetti fell down from my pockets all around me. It really was a honor!

(Feb 8th, 2024) Another Change of HostI’m temporarily moving this website to a different host, still with Hetzner but I’m playing around a bit. SSL certificates will soon change as well. The new IP will be 49.13.21.214(Jan 25th, 2024) ML Model Collapse as Radionuclide Contamination in Post-War SteelI keep hearing that ML models such as LLMs and other transformers are prone to "model collapse", i.e., the process according to which the behavior of these models degrades over time due to the progressive ingestion during the training phase of more and more ML-generated content. For example, the more and more ChatGPT is used, the more and more the Internet gets flooded with ChatGPT-generated content, and therefore subsequent iterations of ChatGPT are trained with less human-made text and more, lower-quality, machine-generated text. Trash in, trash out.

It looks like this problem is here to stay and it is so bad that, apparently, some AI companies are already scraping the Internet Archive for pre-ChatGPT content. This phenomenon gives a huge advantage to companies like OpenAI, which entered the business first and have therefore made it in time to stock large datasets of "pure" data.

Here is a random thought. This feels similar to the search for low-background steel in radio-sensitive detectors and applications. This steel is scarce and precious, usually salvaged from pre-1940 sunken vessels - just like data scraped at low-bandwidth from the Internet Archive.

I hope that, just like the need of this pre-war steel became mostly obsolete after the nuclear ban treaties, we will reach at some point some form of AI treaty which will make it possible to flag most of machine-generated content as such. Technically, I have no idea how to do that, but life taught me to not underestimate the power of social norms and regulations, so who knows?

(Nov 13th, 2023) A Trick to Speed up RSA Modulus GenerationRecently I had reasons to recall something that happened in 2019 at Kudelski Security during some client project. At some point there was a discussion on how to speed up the generation of RSA keys. As you might know, you need two primes roughly of the same size, p and q, but they cannot be "any" primes, they must be (among other things) "safe primes". In particular, they must have the property that (p-1)/2 and (q-1)/2 are still prime. And this is annoying, because first you must spend a lot of CPU time generating a large prime, and then maybe you have to discard it because when you check the condition above it doesn’t hold. That’s a big bottleneck of RSA key generation.

Then I made the observation (and I cannot believe I’m the first one to have made such observation) that for this property to hold, the last 2 LSB of the prime must *both* be 1, because large prime implies odd, so modulo 2 must give result 1 both for the candidate prime and its half. So, having these 2 LSB both set to 1 is a very minimal condition to ensure that your numbers are candidate safe primes.

The way this was implemented in the project we were working on (e.g., for a 2048-bit RSA key, so 1024-bit primes) was the following:

1. Generate a random 1024-bit string.

2. Set the first MSB and the last two LSB to 1.

3. Test the 1024-bit number obtained for primality; if fail then goto 1.

4. Right-shift this 1024-bit number by one bit.

5. Test the 1023-bit number so obtained for primality; if fail then goto 1.

6. Return the 1024-bit number as a safe prime. Which is cool but I made the following observation. The method below is probably faster in most cases:

7. Generate a random 1023-bit string.

8. Set the first MSB and the last LSB to 1.

9. Test the 1023-bit number obtained for primality; if fail then goto 1.

10. Left-shift this 1023-bit number by one bit and set the LSB to 1 again.

11. Test the 1024-bit number so obtained for primality; if fail then goto 1.

12. Return the 1024-bit number as a safe prime. This algorithm looks very similar to the first one above, and for sure it produces the same output, but it’s not the same. In fact, when we tested it, it was indeed slightly faster than the first one.

The intuition is the following: testing a 1024-bit odd number for primality is slightly more expensive (and slightly less likely to succeed) than testing a 1023-bit one. You might arguably say that the difference should be minimal (and you’d be right in general), but these 1024-bit numbers are not really random odd numbers: they are all set to be 3 modulo 4, which means that the probability of one of them being prime is even less than what you would expect for a random 1024-bit odd number. So this is to say that, in both algorithms above, the 1024-bit testing is actually quite trickier than the 1023-bit testing.

In the first algorithm you do "the hard work first", by repeatedly doing the 1024-bit testing. But then, when you finally have a positive match, you are not guaranteed that the right-shifted 1023-bit number obtained is still prime - in fact, that’s a small chance of it happening. In the second algorithm, instead, first you do a lot of 1023-bit testing, and for each candidate you do the "difficult" 1024-bit testing. The overall number of primality tests is roughly the same, but the difference is that in the first algorithm you do many "hard" tests and few "easy" ones, while in the second algorithm you do many "easier" tests and few "hard" ones.

This difference is enough to be detectable. I don’t remember exactly the numbers but I seem to recall something like 2% on a Go implementation - feel free to correct me. So, keep this in mind when you implement your own RSA key generation cryptography - just kidding, don’t do that!

Also, this is n00b stuff, I’m sure there is zillion of better ways to generate RSA primes in a much more efficient way.

(Oct 7th, 2023) Shufflecake Accepted At ACM CCS 2023I can finally break the confidentiality embargo and proudly give the big announcement: The Shufflecake research paper (coauthored with Elia Anzuoni) has been accepted at ACM CCS 2023! We are super excited to present Shufflecake at one of the most prestigious cybersecurity conferences worldwide. A 50-page full version will be available in the next couple of days both on ArXiv and IACR’s Eprint. Check the Shufflecake website or the Shufflecake Mastodon for news.

There is a lot of "meat" in the full version, especially regarding future works and planned features. The most pressing point, as previously explained, is the topic of crash consistency. We have ideas on how to do that, but we are still working on implementations.

Many people will probably find the discussion on the topic of multi-snapshot security most interesting. We know that in order to achieve multi-snapshot security we NEED to use WoORAMs, but they are very slow. Our insight is to try to achieve a weaker version, "operational" multi-snapshot security, which (we argue) should be enough in real-world scenarios.

But my favourite topic, and one that I think has been foolishly overlooked in previous literature is the topic of "safewords". What is a safeword in the context of plausible deniability? It’s the idea that a user might want to have the "last resort" possibility to surrender to an adversary and prove that she has nothing to hide. The concept would be: If I’m caught by my CS teacher doing non-school activities on my laptop, I can use plausible deniability and be un-prosecutable in front of the principal, but if the police comes knocking at my door, I don’t want to get in trouble and I want to comply - and PROVE that I am complying.

With TrueCrypt this is easy: just give up the decoy password to the principal and the real password to the police. In Shufflecake and similar systems that’s not so easy, because there are many layers of nested secrecy. So "the adversary does not know when he can stop torturing you" because he cannot trust you whatever you say.

Is this good or bad?

In the paper we make the following points.

1. It is actually possible to implement a safeword even on systems such as Shufflecake. It’s an easy trick really.

2. The idea of a safeword is SUPER BAD for plausible deniability. Not only you should NOT USE a safeword, but the mere POSSIBILITY of having a safeword degrades the operational security of the scheme.

3. This problem does not seem to have been addressed before on existing constructions, as all of them (even WoORAM-based ones) have the implicit possibility of creating a safeword.

4. We propose an idea to make Shufflecake "safeword-free"! This is future work but it’s definitely going to be implemented at some point. The idea is that we can make ANY kind of safeword-like feature impossible by implementing a nice hack to have potentially INFINITE nested volumes (rather than limited by an artificial hard-limit, which is 15 in the current implementation). I want to expand a bit here on the last idea. Nothing of what I write down here has to be intended as rigorous, this is just the high level intuition. STRICTLY FUTURE WORK!

Currently, Shufflecake packs all the headers (DMB and 15 VMBs) at the beginning of the storage space, and data sections come afterwards in the form of 1 MiB slices. If we want to have the possibility, at least in theory, of having an unbounded number of volumes, then we need an infinite (subject to total storage space) number of headers, and hence we cannot pack them at the beginning of the disk. Clearly, most of these headers will actually be "bogus", i.e. they will not be headers at all, but the adversary should never be sure about that.

So my idea was the following: imagine we don’t have a DMB and 15 VMBs, but just a unified, per-volume "header" (encapsulating everything we need for opening the volume, including its encrypted position map), and suppose that this header is one slice large. What we can do is: having the first header (for the first volume) at the beginning of the disk, and the others at random positions across the disk space, interleaved between the other data slices. If everything is encrypted, the adversary cannot tell whether a slice is a data slice or a header, and hence cannot tell exactly how many volumes are there, or even what MAXIMUM number of volumes there can be.

This is cool, it makes safewords impossible! No artificial limit on the maximum number of volumes. But there are challenges.

First of all, how do we "navigate" this chain of headers? We know where the first one is, but what about the others? The idea is to have every header pointing at the position of the next one through a dedicated field. But how about this field? We cannot encrypt it: We would need to encrypt it with the password of the CURRENT header, but then it would be useless for plausible deniability (the adversary will know the position of the next header). We could encrypt it with the password of the next header then. This works if we only have two volumes, but what if we have three instead, and we want to unlock the third one? There would be an unnavigable "gap" in the chain.

My solution is simple: this pointer field is simply left unencrypted, but ANY random string could be a valid pointer. In practice, the concrete idea is to have a random value in the header, say 128 bit, and use it as an input to a linear function which maps uniformly to all slices of the disk: the string "0x0..0" would be the first slice, while the string "0xF...F" would be the last slice, and anything in between would point to other slices linearly. Clearly, random values that are close to each other would point to the same slice, but this is OK. The observation now is the following: even without having any password, the adversary can navigate from the first header to the position of the second, to the third, and so on, but she will not know when to stop, because there will be no way of knowing when the "real" chain is over! The adversary would keep jumping back and forth on the disk like crazy, but no guess on the number of volumes!

Except... three problems.

The first problem is that there actually IS a way for the adversary to know that, starting from a certain point, surely the chain is finished, and she is now inspecting data slices rather than headers. This happens if there is a loop. No header can point to a previous one, so if this random value points "backwards", then we know that something is wrong. But notice that headers will actually be a negligible amount of the disk space, so the chance that a random value points to one of the existing headers is negligible. Sure, it will happen sooner or later along the chain, but we cannot know in advance when. This is sufficient to argue that: in no way a user could use a safeword to "limit" the growth of this chain.

The second problem is: what happens if, during use, modification of a data slice "breaks" the chain? Well, also not a big deal: Notice that Shufflecake would know exactly the position of all unlocked headers, and would treat those slices as permanently occupied, so no risk of overwriting one of those. The only possibility would be to overwrite a "bogus" header, thereby breaking the chain of fake headers. But for the adversary, without the right password, everything is a link of the chain, even the new (encrypted) data slice! So, all that changes is the chain, which (after that slice) might now point to completely new areas of the disk, but this doesn’t break anything for the user.

But, wait, then could the adversary know how many "real" headers are there by looking at the state of the chain over time? Yes, this is possible: Every time the adversary sees a change of chain at link N, she knows that the number of volumes is AT MOST N-1, and every observation can shrink down this estimate. This is a problem, but it depends on how often the data slices change, and anyway we are now in the multi-snapshot regime. Things become quickly complicated here, but also solutions multiply. We can use re-randomization (since we use AES-CTR), or we could do some brute-forcing to make sure that the random pointer lands somewhere we want. In any case, the accuracy to which an adversary identifies the real number of headers depends on the number of snapshots she has, which cannot be too many because TRIM is not an ever-growing blockchain...

The last problem is: how about the slice maps? Those are usually larger than a single slice, they can’t fit into a single header so defined. True, but nothing changes if the header is 2 slices large, or 3, 4, 5, etc. Just use the same schema: every slice of a header points to the next one, and the last slice points to the first slice of the next header, and so on. This also has the advantage that we can use more or less slices for a header, depending on the size of the device. We also can embed as much volume metadata as we want.

Cool stuff!

(Aug 17th, 2023) Back From Vegas, Black Hat, DEF CON, Shufflecake News, Etc...Let’s try to have a proper post for once after a long time. I’m back from Vegas, from my first Vegas. It was tiring, it was productive, it was exciting, but mostly it was so that I hope it won’t be my last Vegas, because I really enjoyed it! Let’s see what happened.

I arrived on Tuesday, Aug 8th in the early evening, after a long, boring and uneventful direct flight. The first impression of the city itself was as I expected it: fake, but in a kind of friendly way. Clearly, this only holds for The Strip, which is pretty much the only part I saw. Time was short and packed. I was there to attend Black Hat and DEF CON, my first time for both of them.

I met with other folks from Kudelski Security. The first thing I learned about Black Hat is that the conference itself is just half of the fun: in the evenings, every evening, people go to "parties", which are more or less exclusive networking events with cheap booze and finger food. So, as soon as I arrived at my hotel I barely had the time of changing myself and go to the first evening party of the week! It was good: I quickly entered "undead mode" and managed to stand straight on my feet until around 10 PM, at which point the reanimation spell which was keeping me going faded, and I barely had the energy to crawl back to the hotel and crash. I still woke up at 5 AM and went to have "burger breakfast" at the casino downstairs with a colleague who was as jet-lagged as I was. Reading twice what I just wrote it sounds super weird but, hey, it’s Vegas!

Wednesday Black Hat itself started. If I have to describe it with a single word I would call it grandiose. I walked so much my feet still hurt, I am not used to a couple of miles just to walk from the breakfast "room" (more "arena") to the talk room. I have to say, I didn’t enjoy Black Hat too much. Too "corporate", talks were less interesting than I expected, and the sight of business people in the vendor booths trying to attract you and subscribe you to their mailing list in exchange for cheap goodies made me feel very sad for them. The other parties I went to varied greatly in terms of quality and fun. I had good times with my colleagues, had my taste of American cuisine, but overall I would not define the first days at Black Hat as very interesting.

DEF CON, on the other hand, was a blast!

A cyberpunk orgy of very special humans and LED lights. Pure chaos, but in a cozy way. People were really friendly, everyone being "as weird as they are", without faking it, and everyone being very friendly and open-minded, or at least this was my experience with the people I interacted with. The only problem with DEF CON is that there is SO MUCH stuff to see and experience, you get quickly overwhelmed by a massive FOMO blast. As much as you can run and scramble from one room to another (huge conference venue here too) there is always something cool you’re missing, a riddle hidden somewhere, a secret party, an art performance, a cool talk not listed on the website, etc. Even if you could split yourself tenfold you’d be probably not enough to experience all of it.

My Shufflecake talk at Demo Labs went well, or at least I got a lot of audience and a ton of good questions. Slides available here. Let me also announce with a bit of delay that the latest version of Shufflecake is v0.4.1, with a ton of improvements and new features.

Regarding the future of Shufflecake, I was asked "is this ready for use or still a beta?". This is a good question. I think that, right now, the only thing that is missing in order to consider Shufflecake a "candidate for stable" is the issue of crash inconsistency. There is a lot of other things that should be addressed, sure, but I’d say that crash inconsistency is the nr. 1 issue. This problem is given by the fact that, unlike traditional disk encryption tools like LUKS and TrueCrypt, Shufflecake uses AES-CTR rather than XTS, and explicitly writes fresh IV on disk every time in order to avoid IV reuse attacks, meaning that if a system crash happens between a block write and the write of the related IV you’re left with undecryptable data on disk. We do this because we want a feature of "block re-randomisation", which we have plans of using in the future for extending Shufflecake’s security to "operational" multi-snapshot adversaries (see it as a "lightweight ORAM"). But, as of now, we do not actually use this feature, which on the other hand gives us 1) performance loss in I/O, and 2) the issue of crash inconsistency. So, we have two ways of addressing this: 1) solving the issue by rendering the block and IV writes atomic. Ther are ways to do it, just with a loss of roughly 11% of space, but we think this would, as a side benefit, improve I/O performance. Or, 2) forget about block-rerandomisation for now, and provide a "lite" mode which uses AES-XTS and will never be able to achieve more than single-snapshot security (but still with all the operational benefits of Shufflecake such as arbitrary filesystems and many nested levels of secrecy). We might actually go for both options and leave the choice to the user, let’s see.

There is some other news about Shufflecake, namely about the academic paper for it, but I’m reluctant to share them at the moment, let’s still wait a bit. Suffice to say that very soon we should be able to publish a version on Eprint/ArXiv. Stay tuned!

(Jul 11th, 2023) Shufflecake v0.3.0 Released!Shufflecake v0.3.0 released! This is a major release with tons of improvements! And there is further news coming soon!(Jul 11th, 2023) I’m on MastodonHell yes, after having escaped the clutches of social media for more than a decade, I decided to give Mastodon a try. You can find me at @tomgag@infosec.exchange but I promise you I will post very rarely.

I’ve been neglecting this homepage for a while now. Thing is, I’m revamping a bit my "personal IT infrastructure", so I guess I’ll try to re-design this website as well. Time will tell.

(Mar 26th, 2023) Change Of HostI’m moving this website to a new host with Hetzner. SSL certificates changed as well. The new IP is 167.235.145.56(Jan 2nd, 2023) Happy New Year, Founding De Componendis CifrisHappy New Year 2776! I’ve been very busy with personal matters recently, but (together with many other Italian academics and professionals) I found the time to join an important event on December 21st: the official founding ceremony of the newly-formed no-profit Italian cryptographers’ association De Componendis Cifris (or, De Cifris in short). Many thanks to the director, Prof. Massimiliano Sala, for organizing the effort.

De Cifris has been already active for many years now, but it was officially formed as a legal entity last month. The reason I decided to join this initiative is that I believe there is both a lack of resources and an abundance of untapped talent in the landscape of cryptologic research in Italy. Even if I’m by now firmly rooted in Switzerland, I’m European at heart, and I always keep an eye on the situation of the motherland. I gladly support actions that can improve the societal, cultural, economical and technological development in the EU, and in Italy in particular.

(Nov 10th, 2022) Introducing Shufflecake: Plausible Deniability For Multiple Hidden Filesystems On LinuxI’m super, super excited to finally announce the first public release of Shufflecake, a plausible deniability tool for disc encryption, aimed at helping people whose freedom of expression is threatened by repressive authorities or dangerous criminal organizations, in particular: whistleblowers, investigative journalists, and activists for human rights in oppressive regimes. You can see it as the "spiritual successor" of software such as Truecrypt and Veracrypt, but vastly improved. Shufflecake is FLOSS (Free/Libre, Open Source Software), source code in C is available on Codeberg (because Github no more, thank you) and released under the GNU General Public License v3.0 or superior.

Releasing this project, and following its development from the beginning until today, was a lot of effort but also really exciting! It allowed me to learn many new things, get my hands dirty with code again after some time, and making myself more familiar with software development in general. And I think the result is really game-changing in the world of privacy, or at least it has the potential to become so. But nothing of all this could have happened without the hard work of Elia Anzuoni. Elia was a MSc student in CS at EPFL (recently graduated), and he applied to the research team where I work at Kudelski Security in search for a topic for his thesis. I pitched the idea for a successor of Truecrypt internally in the team back in 2020 already (my interest for plausible deniable disc encryption software dates back at least to 2011) but so far I hadn’t had the opportunity of supervising a student on the project. But with Elia it was a blast! Shufflecake is based on the work of his thesis. Also thanks to his EPFL advisor. Prof, Edouard Bugnion, who had very insightful ideas and recommendations to make the thing work.

Learn more about Shufflecake on the Kudelski Security Research Blog.

(Nov 9th, 2022) A Few Notes On Resetting A Git Repo To An Initial State And Delete Commit HistoryA few notes for self-reference. When preparing a private repository for public release, sometimes you might want to "clean up the mess" beforehand. The lame solution is to delete the repo and then recreate it through a local copy (spoiler alert: don’t). The following commands, harvested randomly through many posts in the interwebz, work well for me:

git pull git checkout --orphan tmp-main git add -A git commit -m 'Initial commit' git branch -D main git branch -m main git push -f origin main git branch --set-upstream-to=origin/main main git gc --aggressive --prune=all git fetch --all git reset --hard origin/main

(Aug 29th, 2022) A Few Notes On Configuring Apache2 And SSL With ACME UPDATE 2025-08-10: Fixed serious error: insecure SSLv2 was left enabled by mistake. UPDATE 2024-07-23: Changed default location of LE SSL certificates. UPDATE 2023-03-20: Added some extra configuration. UPDATE 2023-01-06: Thanks to the person who kindly pointed out some possible configuration improvements that give me now a score of "A" on SSL Labs.

Today I finally defeated my laziness and got into configuring HTTPS mode for this and other websites. I am using Apache and Let’s Encrypt as a CA, but I don’t want to use LE’s default "certbot" tool for this. I opted for acme.sh instead, which can do everything I need in a few lines of Bash and without root.

First of all make sure that you have write permission on the webroot directory of the website. In my case this is /var/www/mysite.net . Needless to say, Apache must be configured to support SSL, so at the very minimum do a2enmod ssl. Added bonus since you’re at it: do a2enmod headers so you can add MIME and XSS protection later. Make sure to only enable strong TLS ciphers (notice: will break compatibility with some older browsers) by making sure these lines appear in /etc/apache2/mods-available/ssl.conf:

SSLCipherSuite TLS_AES_256_GCM_SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 SSLCompression off SSLHonorCipherOrder on SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)" SSLSessionTickets off

You must also decide where to store key and cert files - don’t include them in the webroot. I opted for /etc/ssl/letsencrypt/mysite.net. Finally, make sure that the Apache website entry in /etc/apache2/sites-available/mysite.net.conf has HTTPS enabled and correctly points to the two (not yet created) files key.pem and cert.pem.

`<VirtualHost 1.2.3.4:80> ServerAdmin admin@mysite.net ServerName www.mysite.net ServerAlias mysite.net *.mysite.net

Redirect permanent / https://mysite.net/

DocumentRoot /var/www/mysite.net Order Deny,Allow Options -Indexes AllowOverride None ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined Header set X-XSS-Protection “1; mode=block” Header always append X-Frame-Options DENY Header set X-Content-Type-Options nosniff

<VirtualHost 1.2.3.4:443> ServerAdmin admin@mysite.net ServerName www.mysite.net ServerAlias mysite.net *.mysite.net DocumentRoot /var/www/mysite.net

SSLEngine on

SSLCertificateKeyFile /etc/ssl/letsencrypt/mysite.net/key.pem

SSLCertificateFile /etc/ssl/letsencrypt/mysite.net/fullchain.pem

<If “%{HTTP_HOST} == ‘www.mysite.net’”>

Redirect permanent / https://mysite.net/

Order Deny,Allow Options -Indexes AllowOverride None ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined Header set X-XSS-Protection "1; mode=block" Header always append X-Frame-Options DENY Header set X-Content-Type-Options nosniff `

Notice the commented lines. Enable the website with a2ensite mysite.net if not already enabled. Now check that the configuration looks OK with apache2ctl configtest. If everything looks OK you can restart Apache with systemctl restart apache2. Point your domain name to the server’s IP if not done already and make sure that the non-HTTPS version of the website works.

Time to install acme.sh:

curl https://get.acme.sh | sh -s email=me@whatever.com

First of all, close and reopen the terminal. Then let’s revert the default CA from ZeroSSL to LE:

acme.sh --set-default-ca --server letsencrypt

Then let’s issue the certificates for mysite.net but changing the keysize at least (yes, I still prefer to use RSA over EC for technical reasons I might write a blog post about in the future):

acme.sh --issue -d mysite.net -d www.mysite.net -w /var/www/mysite.net --keylength 4096

Finally, let’s transfer the generated certs to their place and specify the apache2 reload command for our installation, which in my case is:

acme.sh --install-cert -d mysite.net --cert-file /etc/ssl/letsencrypt/mysite.net/cert.pem --key-file /etc/ssl/letsencrypt/mysite.net/key.pem --ca-file /etc/ssl/letsencrypt/mysite.net/ca.cer --fullchain-file /etc/ssl/letsencrypt/mysite.net/fullchain.pem --reloadcmd "systemctl restart apache2"

CAVEAT: for the last --reloadcmd parameter, I guess root is required. Technically speaking, it might not be totally necessary, but I’m afraid it will make autorenewal fail. Well, let’s see after 60 days what happens, we’ll find out. (UPDATE 2022-11-09: I still haven’t figured it out whether it works or not, because in the meantime I had to restart apache manually a couple of times, so I’m still not 100% sure)

Anyway, let’s complete by removing the placeholder comments on the lines of /etc/apache2/sites-available/mysite.net.conf so to enable the SSL engine (these lines will remove the non-HTTPS version of the website because it’s 2023 now), then reload Apache with systemctl restart apache2 et voila’!

(Jul 6th, 2022) NIST Finally Announces End Of PQC Standardization 3rd RoundAfter a couple of months of delay due to "legal reasons", NIST has finally announced the end of the 3rd round in the PQC standardization process - standardization of quantum-resistant cryptographic algorithms. The first winners of the competition are the following:

• For KEMS, only one: CRYSTALS-KYBER (due to the small encapsulation size, keysize, and fast performance, which makes it substantially a forced choice as a TLS drop-in replacement)
• For signatures, the following: KRYSTALS-Dilithium (mainly due to speed), Falcon (as a fallback in case Dilithium signatures are too large for applications), and SPHINCS+ (because it’s just rock-solid and based on completely different security assumptions unlike the previous two both based on structured lattices). Furthermore, there is other 4 finalists KEMs that will advance to the 4th round:BIKE, Classic McEliece, HQC, and SIKE.

• Both BIKE and HQC are based on structured codes, and either would be suitable as a general-purpose KEM that is not based on lattices. NIST expects to select at most one of these two candidates for standardization at the conclusion of the fourth round. SIKE remains an attractive candidate for standardization because of its small key and ciphertext sizes and will continue to study it in the fourth round. Classic McEliece was a finalist but is not being standardized by NIST at this time. Although Classic McEliece is widely regarded as secure, NIST does not anticipate it being widely used due to its large public key size. NIST may choose to standardize Classic McEliece at the end of the fourth round.*

Needless to say, this is great news. I was expecting Falcon to win but not Dilithium, which in my opinion is worse under many realistic scenarios, but having both doesn’t hurt. I was not sure NIST would standardize SPHINCS+ already at the end of the 3rd round, I think the origi