This page archives the rules from the 2015 Crypto Village contest. They are not the current rules.
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.
We’d like to do the same for cryptography. We want to see if you can design a crypto system that looks secure to experts, yet is backdoored or vulnerable in a subtle barely-noticable way. Can you design an encrypted chat protocol that looks secure to everyone who reviews it, but in reality lets anyone who knows some fixed key decrypt the messages?
We’re also interested in clever ways to weaken existing crypto programs. Can you make a change to the OpenSSL library that looks like you’re improving the random number generator, but actually breaks it and makes it produce predictable output?
If either of those things sound interesting, then this is the contest for you.
There are two categories of submissions. Each category will be judged independently:
- GPG Key Leaking: Patch the GPG source code, to leak the user’s private key in a subtle way. The leak should be performed in such a way that the average user would not notice it. Annotated samples must be included to demonstrate the technique and its effectiveness.
- Password Hashing Backdoor: Design and optionally implement a password hashing system or password-based authentication protocol that, when a secret value is supplied, will allow an attacker to authenticate to any account. The system should appear secure under a typical peer review. Bonus points for a working implementation. The design should be documented in a plain text ASCII file, or PDF file.
The secret value may depend on the account, and it is acceptable if the attacker must first steal the stored hashes in order to learn it. The more your entry assumes about the attacker’s capabilities, the less highly it will rank, unless those assumptions make the backdoor harder to detect. You may also give the attacker capabilities as part of your submission, e.g. by including a side-channel vulnerability that lets them leak the stored hash, instead of just assuming they have stolen the hash database.
We will begin accepting submissions on 7/31; all submissions must be sent to[email protected] by 8/8 at 8AM. Submissions not received by this deadline will not be reviewed, and are not eligible to win.
Submissions must be in the following format, sent as a compressed file (zip, 7z, gz, etc.) to the email address above.
- submission/ – The “contents” of your submission, e.g. a patch, a design document, some code, or whatever.
AUTHORS.txt PRIMARY CONTACT NAME / HANDLE: PRIMARY CONTACT EMAIL: PRIMARY CONTACT TWITTER: NOTE: Attendance of the Announcement is not required to win, though it may not be possible to deliver any prizes or participant cards. This answer will not be used as a factor in judging, only in event planning. PRIMARY CONTACT WILL BE AT ANNOUNCEMENT (8/8 @ 5PM): NOTE: Winners, and some selected participants may be offered the opportunity to speak briefly (less than 5 minutes) about their entry. If there are slides that you would like displayed (3 maximum) during this time, they must be included in the /submission/ directory. While we will try to offer this time to the best participants, we can not make any guarantees that it will be offered in any event. INTERESTED IN SPEAKING AT ANNOUNCEMENT: LIST NAME / HANDLE / EMAIL / TWITTER OF ALL TEAM MEMBERS:
README.txt NAME OF PROJECT: WAS THIS A TEAM PROJECT: PROJECT LICENSE: CHALLENGE (GPG KEY LEAK / PASSWORD HASHING BACKDOOR): NOTE: The project description should explain your entry clearly; including the techniques used, why it works, why you think it would go undetected. It may be a summary of a longer document included in the /submission/ folder. This description will eventually be published on the Underhanded Crypto Contest web site, along with the contents of the /submission/ folder. This must clearly describe the entry to the judges; to respect the time of our judges, they will not take the time to hunt for the techniques used. The description should be 500 to 2000 words. DESCRIPTION:
The only conditions are:
- The crypto design (if applicable) and an explanation of the bug must be specified in English, in a PDF or plaintext ASCII file.
- Implementations can be in any human-readable language (assembly is OK).
- Code and related documentation must be under a free software or permissive license (GPL, MIT, BSD, CC0, etc.)
We will keep submissions secret until they have been judged. Winners will be announced on 8/8 at 5PM; shortly thereafter the winning submission for each category will be published. All remaining submissions will be published in the weeks after the winners are announced.
Team submissions are allowed. If a team submission wins, the list of individuals’ names or handles will be listed in the announcement. Teams must pick one representative member at the time of submission and the prize will be given to that member.
Multiple entries per person / team are allowed, though to protect the valuable time of our judges, the contest organizers reserve the right to reject submissions from anyone believed to be abusing this privilege.
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.