Rules for the 2017 Underhanded Crypto Contest
The Underhanded Crypto contest was inspired by the famous Underhanded C Contest, which is a contest for producing C programs that look correct, yet are flawed in some subtle way that makes them behave inappropriately. This is a great model for demonstrating how hard code review is, and how easy it is to slip in a backdoor even when smart people are paying attention.
The Underhanded Crypto Contest is the same but for cryptography. We welcome backdoors in implementations of cryptography (in any language) as well as backdoors at the design level so that any implementation of the design would contain a weakness.
This year, we’re accepting all kinds of submissions, as long as they have something to do with cryptography. Your entry can take the form of a patch to the code of an existing cryptography project, a description of the way you could modify an existing design to add a backdoor, your own design for an entirely new cryptosystem, or anything you’d like. Of course, entries that come with a proof of concept implementation or are very well explained are most likely to be rated highly by our judges.
To help you out, here’s are a couple of categories we’d like to see submissions for this year.
- Backdooring random number generators. Suprisingly, we’ve only ever had one submission for a backdoored random number generator, back in 2014 by Solar Designer. Random number generators are important to almost every aspect of cryptography, so they’re a great thing to backdoor. And it’s hard to tell when a number is random and when it isn’t, so there’s lots of room to add an undetectable backdoor.
Deceptive APIs. A lot of design work in modern cryptography goes into making crypto library APIs easy to use, or more importantly hard to misuse. To do that, we need to better understand why some APIs are more susceptible to being used incorrectly. So, here’s a challenge: Design a crypto library API that looks like something developers would want to use, but that would probably end up being used wrong (in an insecure way) in practice.
You are not required to to work within these categories, and entries in these categories will not automatically be ranked any higher than unrelated entries.
To submit an entry to the contest, simply email it to [email protected]. We’re
accepting submissions from now up until July 1st.
To make the process easier for our volunteer judges, we ask that you put your submission in the following format. Please send your entry as a compressed folder (.tar.gz, .tar.bz2, .zip, .7z, etc.) with the following structure:
README-JUDGES.txt– An explanation of your submission for the judges to read. This must explain what all the files in the
AUTHORS.txt– The list of people who worked on your entry. See the template below.
LICENSE.txt– The open source license your submission is released under (CC0, GPL, MIT, BSD, etc.)
submission/– A directory containing the technical contents (code, etc.) of your submission.
blogpost/– This is totally optional, but if you’d like us to post your explanation of our entry on our blog, you can include a “blog post style” explanation here. Please write your blog post in either plain text or markdown. You can include some images too if they’ll help explain your entry. We can’t guarantee that we’ll publish it, but if it’s well-written and explains something neat, there’s a high chance we will!
README-JUDGES.txt must explain what the stuff in the
submission/ directory is, and must completely reveal the weakness in your entry (don’t try to make the judges find your backdoor!). In this file, explain to the judges what your entry does, why it’s hard to detect, and why it is a valuable entry that deserves to win. Keep it succinct please, our judges are volunteering their time!
The AUTHORS.txt file should contain the following contents for each member of your team (or just yourself if you’re working alone). The authors will be listed on the website in the same order you place them in this file, so it is up to you if you want to put them in order by contribution or alphabetical.
Which author is the primary contact for your team (required if you have multiple authors)? Author #1 ========= Which email address should we use to contact you? (required) What name / pseudonym would you like us to use for you on our website (required)? Is there a website you'd like us to link to on our website when we mention your name (optional)? What's your Twitter handle (optional)? Author #2 ========= ... repeat the questions for each author ...
Plagiarism is strictly forbidden. You are encouraged to build on previous work, but if you fail to cite it or don’t explain how your work is different from what came before, your submission will be rejected.
We’re working on getting some sweet cash prizes for this year’s winners.
Judging is done at our discretion. The judges will be volunteers (usually cryptography/infosec experts) who are independent from the contest organizers, and they will be free to judge the entries in a fair way that’s compatible with the amount of time they are willing to devote to the contest.
Announcing the Winners
We’ll announce the winners around the same time as DEF CON 25 (late July).
The contest organizers and judges are not eligible to participate in the contest. Prizes may not be available should the winner(s) live in a country subject to embargo by the United States or Canada, or due to other legal restrictions. In the event that prizes can not be awarded due to legal restrictions, the contest organizers will make a good faith effort to resolve the situation within the applicable laws; if it is determined that the situation is not reasonably resolvable, the prizes will be donated to an appropriate charity.
If a winner does not wish to provide the identifying information necessary to deliver any prize(s) they have won, the prize(s) will be donated to an appropriate charity.