The competitive and often opaque talk selection process of infosec conferences can be confusing and discouraging. If you submit a talk—an abstract plus a longer description and a biography—and your talk gets rejected, most of the time you won’t get any useful comment from the board justifying their decision. Submitters then often perceive the process as arbitrary, driven by hype, favoritism, and egos. This isn’t always wrong, but not all conferences look like cosplay-free comic cons. Conference organizers should be given some credit for trying to maintain a reasonable technical level while at the same time covering a wide range of topics and having broader-than-deep talks to get less experienced attendees excited about this or that topic.

To put the odds in your favor when submitting a talk, it helps to follow advice such as these by Enno Rey, Sean Metcalf, or Nathan Hamiel. There’s lot of experience speaking here, yet I’d like to add my two satoshis from a cryptographer’s perspective. I’ve been sitting in many program committees of academic conferences, but only in a handful of infosec conferences committees, which turned out to be quite a different game. My point of view is therefore more on the submitter’s side, after having talked at a bunch of high-profile cons such as Black Hat, Defcon, BSides, CCC, Shmoocon, Troopers, SyScan, or Infiltrate. I haven’t counted my ratio acceptance/submissions, but my submissions have rarely got rejected. One reason is obviously that there’s more demand than there’s offer for serious crypto talks. But I think I’ve also learnt how to prepare submissions that don’t suck and increased my chances of getting in.

As a submitter, your job consists in two things:

  1. Do great work, be it pure research, survey of a topic, or opinions.
  2. Describe it convincingly in your submission.

It’s worth mentioning that 1. should be done before 2., and 1. should not be (only) motivated by 2.

Given these two dimensions, and to simplify a lot, there are four classes of submissions:

  1. Great work + convincing description: Ideal case, likely to be accepted.
  2. Great work + unconvincing description: May be accepted, if reviewers know the topic well enough to go past the poor description.
  3. Poor work + convincing description: May be accepted, alas, if reviewers don’t know the topic well and you BS well enough to fool them.
  4. Poor work + unconvincing description: Likely to be rejected, and deserved.

Of course who you are or who you work for will also weigh in the selection process, but you can’t do much about it. So let’s focus on 1. and 2.

1. Do great work

Whatever your work, you should bring original, non-shallow thoughts to the table. New is better than non-new, breakthrough is better than incremental. But this isn’t sufficient. Your work should also be useful to your audience, and this helps if it addresses a problem that people have, now. In other words, your submission should be timely.

But reviewers will often struggle to judge of the quality of a work. They often have to use heuristics, and will typically assess the speaker’s expertise: Have you published some work that demonstrate the extent of your expertise? Have you previously published in well-regarded venues? And so on. This doesn’t (and shouldn’t) imply that veteran researchers get a free pass for weak submissions, but that, justifiably, the barrier to entry for them is lower.

Also keep in mind that “great” may not have the same meaning to you than it will have to the review board. If you’re a cryptographer, for example, you may think that your new multidifferential attack technique applied to break 9 rounds of AES in only 2^125 complexity is great. But people at the conference won’t care, sorry.

2. Describe it convincingly

Your submission, namely an abstract and whatever else is asked for, shouldn’t sound like it’s been written by an idiot. Clear writing is clear thinking. Be concise. Structure your description in different parts with logical connections. Read Zinsser. Provide the details that will convince reviewers—and later participants—that you know what you’re talking about, but don’t get caught up in irrelevant details. Try to make the reviewers’ lives easier.

In con submissions as in many other endeavors, trying too hard is counterproductive: Don’t exaggerate your findings nor their impact. Be careful with superlatives, jokes, and words like “cyber” or “pwnage”; you’ll sound immature. In your submission, don’t promise what you’re not sure to be able to deliver. And don’t BS, it harms everyone.

Talks are better with demos, but only good demos. A good live demo is better than a good screencast demo, but it’s also harder. Depending on what you’re demoing, the choice between live and screencast may be obvious. In any case, a submission will sound more convincing if you say “I’ll demo X and Y and Z” than if you just say “there’ll be a demo”.

Closing remarks

After receiving good news from the conference, make sure to deliver a good talk, it will increase your chances with the next submission. If you get the reputation of a good speaker then review boards are more likely to excuse shortcoming in your next submission.

Don’t think that having talks accepted means that you’re a genius. Actually, most of the best people don’t talk at conferences, and don’t care. See the scientific diagram below.

While you might think that your reputation precedes you, different conferences have different expectations and, most importantly, different audiences. Always work hard on the submission and don’t think that your name plus a rushed abstract will suffice. Of course you will feel rejected when your submission gets rejected. But complaining on Twitter is, at best, a nuisance, at worst counterproductive towards your next submission. Your talk, while brilliant, might quite simply not be appropriate for the intended audience.

Thanks to Arrigo Triulzi and Halvar Flake for their comments on a draft of this post.

Jean-Philippe Aumasson

Jean-Philippe Aumasson

Principal Cryptographer at Kudelski Security
Jean-Philippe (JP) Aumasson is Principal Cryptographer at Kudelski Security. He is known for designing the cryptographic functions BLAKE, BLAKE2, SipHash, and NORX. He has spoken at conferences such as Black Hat, RSA, and CCC, and initiated the Crypto Coding Standard and the Password Hashing Competition projects. He co-wrote the 2015 book “The Hash Function BLAKE”. He is a member of the technical advisory board of the Open Crypto Audit Project and of the Underhanded Crypto Contest.
Jean-Philippe Aumasson

Latest posts by Jean-Philippe Aumasson (see all)