by Jean-Philippe Aumasson | Oct 5, 2017 | CISO
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:
- Do great work, be it pure research, survey of a topic, or opinions.
- 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:
- Great work + convincing description: Ideal case, likely to be accepted.
- Great work + unconvincing description: May be accepted, if reviewers know the topic well enough to go past the poor description.
- Poor work + convincing description: May be accepted, alas, if reviewers don’t know the topic well and you BS well enough to fool them.
- 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.
by Jean-Philippe Aumasson | May 3, 2017 | Cryptography
A few years ago, a customer handed us a report from a Big 4 consulting firm describing how, after close to 100 person-hours of review, a team of ‘highly-qualified senior security engineers’ had failed to find any flaw in their encrypted communications product. Half a day later, I had worked out how to break the product’s encryption, and demonstrated a working exploit. The customer was confused—why hadn’t the well-dressed consultants caught the vulnerability?
One possible reason is that such firms will often present as ‘senior engineers’ or even ‘experts’, junior hires whose only expertise is a night browsing about the subject matter. For an hourly rate of $250. But that’s another story.
The reason it took me half a day to discover the flaw is principally to do with skillsets. Crypto requires specific skills. Like a good general surgeon won’t necessarily be a good heart surgeon, a good all-around security engineer won’t necessarily be the right person to review cryptography products.
Why Crypto Is Hard
To be honest, I don’t think that crypto is intrinsically harder than other domains of information security. I find crypto much simpler than, say, browser security. But crypto is viewed as hard because it requires totally different skills, especially mathematics, and because it involves security notions that aren’t used elsewhere. A security engineer can have years of experience in web security, application security, and network security, yet have little exposure to concepts such as forward secrecy or indistinguishability.
Of course, bugs in cryptographic software can be the same kind bugs as is any piece of software, bugs such as buffer overflows or use-after-frees (think Heartbleed). Finding logic bugs, however, often requires an understanding of the crypto protocols and their subtleties. Even harder is cryptanalysis, the task of studying properties of cryptographic designs and implementations. Doing cryptanalysis for a general security engineer is like asking a cryptographer to reverse engineer an obfuscated binary program. If you don’t have thousands of hours of experience, you won’t find the subtlest vulnerabilities (such as these), and it will take you days to do what an experienced person would do in hours.
An additional risk with crypto is that of side channels, or the leak of information about secret material from the program’s behavior. This class of bugs includes for example timing leaks, which occur when the execution time of a program reveals information on the cryptographic keys. A common side-channel attack in software applications is the padding oracle attack (alas, not yet eradicated).
The bottom line is that reviewing crypto is much more than checking what algorithms are used, as I’ve previously blogged about.
What To Do About It
To review the crypto in your crypto product, hire cryptography experts who are used to doing this kind of job. Purely academic researchers may help for the more theoretical analysis, but are rarely familiar with practical considerations.
You’ll find such crypto experts either in large security companies, or in smaller shops specialized in crypto reviews. It can be hard to identify the qualified teams though. A sign of ability is the publication of vulnerabilities or presentation of their research at conferences. Note that the absence of evidence is not evidence of absence; some companies choose not to publish anything.
Another approach, especially if part of your code is open-source, is to organize a bug bounty and offer a reward to discoverers of vulnerabilities including crypto vulnerabilities.
In any case, to prevent failures in your crypto product, follow the usual advice: refrain from creating your own protocol or algorithm and rely on time-tested software components.
And beware marketing. All that glitters is not gold, and with a view to getting a generous slice of an increasingly lucrative market, security companies are keen to package up their infosec-related skills as crypto-specific ones. Dig beneath slick marketing to find out if there is substance to the claims or, as Nomx experienced earlier this year, you could well end up with a Pi(e) on your face.
by Jean-Philippe Aumasson | Nov 27, 2016 | Uncategorized
This is a summary of the talk “Quantum Computers vs. Computers Security”, given at the DEF CON 23 Hacking Conference in Las Vegas in August 2015 by Kudelski Security Principal Cryptographer, Jean-Philippe Aumasson.
Increasing numbers of cybersecurity experts and stakeholders are watching developments closely in the field of quantum computing. A quantum computer is a model of a computer that works completely differently from a classical one. It’s based on phenomena of quantum mechanics that facilitate the resolution of certain problems that classical computers cannot solve, e.g. breaking the crypto used for e-commerce transactions. How does a quantum computer work? Although it leverages complex quantum mechanical phenomena, the core concepts are pretty simple:
- Whereas a classical computer works on bits that are either 0 or 1, a quantum computer works on qubits, which can be 0 and 1 simultaneously. In quantum physics, this is called superposition.
- Superposition is characterized by some probabilities, but not the usual ones: a quantum computer relies on negative probabilities, which are called amplitudes.
- The actual computation is not performed with usual computer operations such as addition or bitwise logic, but uses basic linear algebra transformations, similar to operations between vectors and matrices like in high school physics.
The good (or bad) news is that quantum computers don’t exist yet. Building a quantum computer is a gigantic and fascinating engineering challenge, and we don’t know for sure if it’s even doable. There’s been some progress over the last decade, and some large companies are investing in quantum computing research – but don’t expect a useful quantum computer within the next decade! Cryptographers obviously pay special attention to quantum computing research. A large enough quantum computer could totally break the RSA and Diffie-Hellman cryptographic algorithms, and more generally, all cryptography based on the mathematical problems of factoring integers (such as RSA) and of solving discrete logarithms (such as Diffie-Hellman and elliptic curve cryptography). In short, if a quantum computer is created today, we’re doomed! But there’s hope: the field of post-quantum cryptography is about creating cryptographic systems that can resist quantum computers. These experimental systems are based on different mathematical problems that are expected to be hard for both classical and quantum computers to solve. One such family of hard problems is that of NP-complete problems, which occurs in many contexts. For example, the problem of finding the optimal scheduling of a group of events is NP-complete. And quantum computers cannot solve NP-complete problems. Quantum physics has more potential applications to cybersecurity than of just breaking crypto:
- Quantum key distribution establishes a secure link between two systems, leveraging quantum physics laws to prevent eavesdropping. Such systems are practical and are being deployed, though their actual added value in terms of security is sometimes disputed.
- Quantum money uses the physical “no-cloning” principle to prevent counterfeiting. Quantum money is only a theoretical idea, and seems difficult to put in practice.
- Quantum machine learning is an emerging field that attempts to leverage quantum computers to improve the efficiency of machine learning algorithms.
