Rules for the 2016 Underhanded Crypto Contest

Introduction

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.

Topic

This year’s contest is focused on cryptocurrencies. Your task is to put a subtle backdoor or weakness into a cryptocurrency, such that someone who knows about the weakness can use it to their advantage. The weakness should be hard to detect; imagine that you’re trying to insert it into the Bitcoin core code and that it will have to pass code review, or imagine that your idea will be submitted to an academic journal and will have to pass peer review. It doesn’t have to be completely undetectable, but the more damage you can do with as little chance of detection as possible, the better.

Your entry can take the form of a patch to the code of an existing cryptocurrency, a description of the way you could modify an existing design to add a backdoor, your own design for an entirely new cryptocurrency, or whatever. The only requirement is that there must be strong evidence that your backdoor will actually work. It is not enough to say “here’s a neat idea, and if you were to figure out these details it would work.” You must actually figure out the details! Of course, a working proof-of-concept is the best way to demonstrate your backdoor.

Submissions

To submit an entry to the contest, email it to [email protected]. We’re accepting submissions now, and the deadline for the 2016 contest is June 1, 2016 Extended to: June 30, 2016.

To make things easier for us and our volunteer judges, we require that you put your submission into the following format. Please send your submission as a compressed folder (.tar.gz, .tar.bz2, .zip. .7z, etc.) with the following contents:

  • README-JUDGES.txt – An explanation of your submission, for the judges to read.
  • 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.
    • README-JUDGES.txt must explain what everything in this directory is!
  • blogpost/ – A directory containing a “blog post style” explanation of your entry. Please put the blog post contents in a plain text file. You may include images in this directory, too, if you want to use images to help explain your entry. Reference the image by its filename in the plain text file.

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; the judges don’t have unlimited time.

The blog post may be published on this website to help popularize your idea. Your audience when writing the blog post is a member of the infosec community who is interested in understanding your idea. Keep in mind that your reader might not have any formal background in cryptography or cryptocurrencies, so it may be necessary to give a higher level explanation than you did in README-JUDGES.txt. The blog posts will be published with you listed as the author, and can include a link to your website.

The entire contents of your submission must be under some sort of open source license. Good candidates are CC0, MIT, BSD, and GPL. Include the license text of the one you chose in LICENSE.txt. Assume everything you send us will be released to the public, but we will keep the entries secret until the judging is complete.

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 of most-contributed to least-contributed or just alphabetical.

 

Which author is the primary contact for your team (required if you have multiple authors)?

Author #1
=========

What email address can we reach you at (required)?

What name / pseudonym would you like to be referred to by on the website (required)?

What website would you like us to link to (optional)?

What is your Twitter handle (optional)?

... Repeat the above for each author ...

Plagiarism is strictly forbidden. You are welcome to build on previous work, but if you fail to cite it or don’t explain how your work differs from it, your submission will be rejected.

Prizes

We don’t have any prizes lined up yet. We’ll be working with sponsors to try and get some cool prizes for the winners!

Judging

Judging is done at our discretion. The judges will be volunteers 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. Not everyone will have time to look over all of the submissions, so it is the judges’ job to select the submission (or submissions) that are noteworthy and deserve to be highlighted.

Announcement of the Winners

The winners will be announced some time around the first week of August.

Eligibility

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.

2016 Underhanded Crypto Contest

The Underhanded Crypto Contest is back for another year!

This year we have a special theme: cryptocurrencies. A cryptocurrency is made up of lots of moving parts that interact with each other in subtle ways, so you have more room to play. There are both more components to target and more potential goals. Your backdoor could let you steal secret keys, steal currency, carry out double-spend attacks, inflate the value of the currency, de-anonymize transactions, and much more. You can do it by applying a classic backdoor technique to encryption code or do it more subtly by mucking with the consensus rules. As long as it has something to do with cryptocurrencies, it’s fair game.

Keep in mind that the world of cryptocurrencies is a vast space, larger than Bitcoin. Submissions that patch the Bitcoin core code are very welcome, but you’re also encouraged to attack altcoins and unimplemented academic work. You could even invent an entire cryptocurrency of your own. We’re excited to see what you do.

You can find the contest rules and instructions for submitting your entry here.

Rules from the 2015 Crypto Village Contest

This page archives the rules from the 2015 Crypto Village contest. They are not the current rules.

Introduction

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.

Categories

There are two categories of submissions. Each category will be judged independently:

  1. 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.
  2. 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.

Submissions

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.

  • AUTHORS.txt
  • README.txt
  • submission/ – The “contents” of your submission, e.g. a patch, a design document, some code, or whatever.

Templates

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.

Eligibility

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.