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 4 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. This is a cloud server instance with an Intel Xeon-E2136 CPU (6 cores / 12 threads @ 3.3 GHz/4.5 GHz) with 32GB of RAM.

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.1 with NO additional language dialect options. The source code must be made of generic C (which in particular excludes the use of inline assembly), and it should be re-compilable and properly executable on any x86_64 CPU using any GCC compiler of version >= 10.1 with any optimization level (i.e. still provide the expected ECDSA signature algorithm in these conditions), and with position independent code related flags (-fPIC, -fPIE and -pie).

The source file is allowed to include the GMP library (version 6.3.0) 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 100MB.
• The REFERENCE COMPILERS must use at most 800MB of RAM to complete compilation.
• The compilation must not exceed 150 seconds.
• The executable must be 50MB in size or less,
• The executable must use 50MB of RAM or less (this includes the stack and all global variables, at the exclusion of the code itself),
• The executable must run in 10 seconds 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 following character strings are forbidden in the source code:
  • "#(wsp*)include", except #include <gmp.h>
  • "extern"
  • "_FILE__"
  • "__DATE__"
  • "__TIME"
  • "__STDC_"
  • "__asm__"
  • "syscall"
  • ".init", ".fini", ".init_array", ".fini_array", ".ctors", ".dtors"
  • "(wsp)asm(nan)"
  where "(wsp)" indicates a white space, "(wsp*)" indicates zero or more white spaces, 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 is not allowed to perform any system call beyond reading from stdin, writing to stdout, performing allocations through brk, mmap and munmap (with some restrictions, that should be enough for using the gmp API), exit(_group) and rt_sigreturn. Any forbidden system call will kill the process as SECCOMP filters are used to enforce this. You can debug your program before submitting it using whatever system calls you want, but remember to remove the forbidden ones when submitting your challenge to the SYSTEM (under Linux, you can trace the system calls of a binary with e.g. the strace utility). The SECCOMP filters setup can be found here in the main.c file, and dedicated explanations here. Please also beware that any warning: implicit declaration of function compiler warning will be caught by the SYSTEM and this will reject your program during compilation.
• The public key of the ECDSA implementation must not be one of the ones from the previous 2021 edition accepted candidates as they are blacklisted.

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 keys of the challenges accepted in the previous 2021 edition are blacklisted in order to avoid blind resubmissions.

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}}{ 10 \text{ seconds} }\;.\]

Code size. The SYSTEM measures the size of the executable and determines the fraction \[f_{\text{size}} = \frac{\text{code size}}{ 50 \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}}{ 50 \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 fourth 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})\;.\]