ianG <i...@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. 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. 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. I think the contest needs a few more rules :-). Peter. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography