Competition Rules

Anyone can create an account and post one or several challenges and/or break one or more challenges on the WhibOx Contest Edition 3 website.

The account owner may remain completely anonymous when creating an account. In addition to creating a login/password, an email address must be entered (in case the ORGANIZING COMMITTEE needs to contact the owner directly). However, the email address is not verified except for basic syntax. Users may e.g. enter their primary email address or, if they are willing to remain anonymous, may use a free service such as Mailinator to create an untraceable email address.

The same person may create several accounts. User accounts are password-protected but passwords CANNOT BE CHANGED and are NOT RECOVERABLE in case of loss. It is the users' responsibility to choose a strong enough password and to keep it in a safe place. Winners will be asked to log in and reveal their real name on the competition website if they want to be publicly awarded during the prize ceremony.

The website is public in the sense that anyone can freely browse it (including downloading challenges) but logging in is required to post or break challenges.

The competition website is referred to as the SYSTEM.

A challenge is a C source program that contains a function with prototype

void ECDSA_256_sign(unsigned char sig[64], const unsigned char hash[32]);

It implements an ECDSA signature algorithm on the NIST P-256 curve under some private key embedded into the code. The function ECDSA_256_sign takes two arguments:

• hash : a pointer to the 32-byte hash of the message to be signed (the hash function is excluded from the implementation),
• sig : the address for the output 64-byte signature.

The C language is the one accepted by GCC 10.2.0 with NO additional language dialect options. The source code must be completely portable and re-compilable towards any target architecture. In other words, it must be made only of generic C which in particular, excludes the use of inline assembly. Note that there is no restriction to a 32-bit architecture as in the first edition of the WhibOx contest. Native 64-bit operations are supported by default and contestants may use them as they see fit.

The source file is allowed to include the GMP library (version 6.2.1) through #include <gmp.h>. Besides that, no #include or extern is allowed in the source code, and more generally linking to external libraries (even the standard C libraries) is forbidden. Any attempt to maliciously attack the SYSTEM or the computer system of contestants will lead to DISQUALIFICATION. In case evidence of malicious code is found in a challenge, contestants are invited to report the issue to the ORGANIZING COMMITTEE directly (whibox.organizing.committee@gmail.com). If contestants are suspicious that some challenge program may contain malware, they may run GCC in docker or a virtual machine, exactly like the server does (using VirtualBox).

Documentation on how the server runs is found on GitHub. Contestants are invited to download and install their own instance of the server if they want to ensure that their challenge will be accepted when submitted.

IPR and copyright disclaimer: contestants may indicate (typically in a header in their source) which license applies to their challenge program, if any.

• The source code must be no bigger than MB.
• The REFERENCE COMPILERS must use at most MB of RAM to complete compilation.
• The compilation must not exceed seconds.
• The following character strings are forbidden in the source code:
  • "#include", except #include <gmp.h>
  • "extern"
  • "_FILE__"
  • "__DATE__"
  • "__TIME"
  • "__STDC_"
  • "__asm__"
  • "(wsp)asm(nan)"
  where "(wsp)" indicates a white space and "(nan)" indicates any non-alphanumeric character. An occurence of either of these strings will lead to a rejection of the challenge program, even if they are embedded in (arbitrarily nested) quoted strings.
• The executable must be MB in size or less,
• The executable must use MB of RAM or less (this includes the stack and all global variables, at the exclusion of the code itself),
• The executable must run in second or less per function call. This is not absolute time but CPU time, measured within a VirtualBox VM by the SYSTEM. Contestants may check that their challenges comply with this limitation by using the utility ulimit with the −t option.

The SYSTEM will reject a program that does not comply with these requirements.

Compliance with the requirements can be tested by downloading and running a local instance of the submission server found here.

A challenge must come with

• the public key corresponding to the embedded private key,
• a proof of knowledge of the private key.

The public key must be pasted into the appropriate field of the submission form as the 128-digit hexadecimal string encoding the 64-byte string \( \textsf{FE2OS}(x_Q) \parallel \textsf{FE2OS}(y_Q)\), where \( \textsf{FE2OS} \) is the "Field Element to Octet String" primitive defined in Section 3.1.3 of the BSI ECC guideline, \( (x_Q,y_Q) \) is the public key (\(x\)- and \(y\)-coordinates) and \( \parallel \) is the concatenation operator.

The proof of knowledge is a Schnorr signature of the empty message under the private key, that is a pair \( (r,s) \) such that \( \mathsf{SHA256}(s\cdot G+r\cdot Q)=r \), where \( G \) is the base point and \( Q \) is the public key. The input of \( \mathsf{SHA256} \) is the padded \(x\)-coordinate (32 bytes). The format of the proof of knowledge is similar to that of the public key. Namely, it is a 64-byte hexadecimal string obtained by concatenating \(r\) and \(s\) (each of them padded to 32 bytes).

A reference implementation with corresponding public key (formatted for submission) and a script to generate the proof of knowledge from the private key are available here.

The performance score of a challenge is measured by the SYSTEM when validating its consistency at posting time. Challenges with a higher performance score collect STRAWBERRY points faster. The score is assigned as follows.

Execution time. The SYSTEM measures the average CPU time consumed by the challenge program and determines the fraction \[f_{\text{time}} = \frac{\text{average time}}{3 \text{ seconds} }\;.\]

Code size. The SYSTEM measures the size of the executable and determines the fraction \[f_{\text{size}} = \frac{\text{code size}}{20 \text{ MB} }\;.\]

RAM usage. The SYSTEM measures the average RAM consumption of the executable and determines the fraction \[f_{\text{memory}} = \frac{\text{average RAM}}{20 \text{ MB} }\;.\]

The performance score of the challenge is evaluated as \[\mathtt{perf\_score} = \log_2 \left(\frac{2}{f_{\text{time}} \cdot f_{\text{size}} \cdot f_{\text{memory}}}\right)\;.\]

Note that the performance score of a challenge that meets the allowed maximal limits is equal to \(1\). Challenges that are either smaller, faster or less memory-consuming get a higher perfomance score.

A contestant may post challenges anytime between the STARTING DATE and the POSTING DEADLINE.

A challenge gets more and more STRAWBERRIES as time goes by, as long as it is not BROKEN. In this third edition of the competition, time has a granularity of 1 minute instead of 1 day.

At the time \(t_{post}\) the challenge is posted, its STRAWBERRY score is set to \(0\). The STRAWBERRY score then increases quadratically with time as \[\mathtt{strawberries} = \mathtt{perf\_score} \times \left(\frac{t-t_{post}}{24\cdot 60}\right)^2\] where \(t-t_{post}\) is the number of minutes elapsed since the challenge was posted and \(\mathit{perf\_score}\in[1,+\infty)\) is its performance score (see above).

If the challenge is BROKEN for the first time at time \(t_{break}\), its STRAWBERRY score becomes \[\mathtt{strawberries} = \mathtt{perf\_score} \times \left(\frac{t_{break}-t_{post}-\left(t - t_{break}\right)}{24\cdot 60}\right)^2 \;,\] meaning that its progression is reversed symmetrically until it reaches \(0\). It then sticks to it.

When the FINAL DEADLINE is reached, the STRAWBERRY scores of all challenges freeze.

A contestant may BREAK any challenge by submitting a candidate key to the SYSTEM. The challenge may be STANDING, or already BROKEN.

Key verification procedure: Given the submitted key, the SYSTEM

1. generates the public key corresponding to the submitted private key,
2. fetches the public key of the target challenge,
3. 3. verifies that the two public keys match.

The submitted private key is erased as soon as the verification is completed.

In case of mismatch, the break is rejected. Otherwise, the submitting contestant is notified that the break is accepted. If the challenge was STANDING, it is declared as BROKEN at the time the SYSTEM accepted the break.

Contestants may BREAK challenges until the FINAL DEADLINE.

Every newly registered user, referred to as a contestant, is assigned a BANANA score initialized to 0.

A contestant whose BREAK has been accepted by the SYSTEM gets a chance to increase their BANANA score. Noting \(\mathtt{strawberries}\) the current STRAWBERRY score of the challenge and \(\mathtt{bananas}\) the contestant's current BANANA score, \(\mathtt{bananas}\) is updated as \[\mathtt{bananas} = \max(\mathtt{bananas}, \mathtt{strawberries})\;.\]