[Cryptography] [cryptography] Underhanded Crypto

Taylor Hornby havoc at defuse.ca
Thu Nov 27 20:02:03 EST 2014

On 11/26/2014 07:01 PM, Peter Gutmann wrote:
> ianG <iang at iang.org> quotes:
>> 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?
> Since some of the organisers read this list and this question may be relevant 
> for other contributors as well I'll ask it here: How much code are you 
> expecting?  In theory a submission for "an encrypted chat protocol" could 
> involve sending in a reimplementation of TLS from which it'll be pretty hard 
> to dig out the backdoor due to the sheer mass of code involved.

We're definitely not expecting that much *new* code. There are two
categories of submissions. "New designs" and "Add a backdoor."

For the second category, you can take an existing implementation and
modify it so that it's backdoored in an underhanded way (extra points if
the backdoor isn't obvious even when you're looking at the diff).

> Can 
> contributors send in code snippets with assumptions like /* Both sides have a 
> shared authentication key */ or /* Both sides have exchanged fresh nonces */ 
> to save having to send in 1,000 lines of code to implement this?  This would 
> allow the reviewers to focus on the code containing the backdoor rather than 
> having to dig through vast masses of support code.

Yes, absolutely. For the "new designs" category, it does not need to be
completely implemented. Even just an abstract description of the system
is fine. For example, a submission might be the description of a new
hash function with a subtly-flawed proof that finding a collision is
NP-hard -- no implementation necessary.

> Even then it's going to be really hard to review, if I send in code containing 
> something like /* 2048-bit MODP Group from RFC 3526 */ someone's going to have 
> to do a byte-for-byte comparison ("is that an 'E' or an 'F'?") of the entire 
> thing to see whether it really does match RFC 3526.  And that's an easy one, 
> if I decide to use parameters from GOST 0177545, held in the Zheleznogorsk 
> Academy of Sciences and currently buried under 3m of snow, who knows how the 
> organisers will verify it.

Yes, it may be difficult. Note that "difficult for the organizers to
verify" might imply "difficult for anyone in practice to verify" so that
may be an avenue towards a good submission.

In general, we're looking for things that would likely be accepted (or
at least not outright rejected) by someone who is familiar with

> I think the contest needs a few more rules :-).

Some of these questions are answered here:



More information about the cryptography mailing list