The Barely Secure Cryptography Competition

Don't let not knowing how to do something stop you.  Learn how to do it.
-- Scott Manley

Goal of this competition is to design and evaluate fast cryptographic primitives. Winner will be the fastest candidate that hasn't been broken yet.

The challenges

Performance evaluation

Winner is determined based on the cycles used to perform a pre-determined task on a Tiger Lake notebook. It is legal to exploit all available hardware features for better speed. I expect winners to use AVX512, but there is no requirement to do so.

Winning strategies

There are three obvious winning strategies. You can submit a new candidate that is barely secure and faster than all others. You can take an existing submission and optimize it to be faster than all others. Or you can submit a new candidate that is not the fastest, then demonstrate that all faster competitors are insecure.

Team efforts are explicitly encouraged.

Code requirements

I have to be able to legally publish the code as part of the competition, build and run it on Linux on a Tiger Lake x86 machine.

Readable C published in the public domain is preferred. Any open source license should be acceptable as well. As are other languages, if I can figure out how to build them.

You might decide to submit assembler code for best performance. In that case please add a reference implementation that humans can read and understand. Same for highly optimized C (or rust or whatever), having a simple reference implementation would be very appreciated.

If I cannot decide whether your code contains a back door, it is too obfuscated and has failed requirements. This is not the ioccc.

How to participate

Send a mail to candidate@barelysecure.org.

If you want to join the mailing list, visit the list homepage or send a mail to discuss-join@barelysecure.org.

Motivations and explanations

Why the competition?

Cryptography is a trade-off between security and performance. Such trade-offs are very common in computing. But usually both sides of the trade-off can be objectively measured. The best known way to determine security involves human effort - have many cryptographers try to break an algorithm and fail after spending significant effort.

That high cost results in many otherwise capable people simply ignoring cryptography, which reduces the pool of people doing cryptanalysis and design choices that are exceedingly conservative and slow. As someone that cares about performance, I simply want faster cryptography.

Why require an offset?

For block encryption, I think the AES competition had design flaws. Lack of a third "offset" input results in fragility. While the block cypher in principle is perfectly secure, the most obvious uses are not. See the ecb penguin.

Why 256bit?

Bitcoin miners can brute-force 2^64 hashes for roughly $25. Assuming the cost for brute-forcing some crypto primitive is about the same, 64bit keys must be considered broken. Extrapolating the cost, 96bit keys could be brute-forced for $100B. That is expensive, but within the budget of multiple nation states and large companies. 128bit keys should be safe for now, but might become threatened within our lifetimes. When designing new crypto primitives, I prefer we jump directly to 256bit.

Why Tiger Lake?

Because it is hardware I own and can easily evaluate on. It is also currently in the sweet spot of relatively new and capable hardware with capabilities that may become ubiquitous in the future while being affordable on a student's budget.

Maybe I should do similar evaluations on Arm, a Macbook or a Raspberry Pi. For now I'll stick to x86.

Is this about crypto-currencies?

No, go away!