[cryptography] Underhanded Crypto
adam at adamcaudill.com
Sat Nov 29 11:39:37 EST 2014
> 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.
We have several great judges that have graciously donated their time for this - so anything that makes it easier for them, I see as a good thing. So, while we’d accept either, the trimmed down version will certainly save time.
> I think the contest needs a few more rules :-).
You are probably right; though for now, the rather open nature of the rules was intentional. A contest like this is complicated, because there are so many ways it can be done - when we started this, it wasn’t clear what kind of submissions that we’d see. So we wrote fairly open rules to make sure that everyone in the field could comfortably submit something.
We are hoping that this will be an annual contest - so this run is something of an experiment, future contest will likely more focused, with tighter rules around what’s expected in the submission. Once the contest is over, we’re going to ask all the participants (contestants and judges) for feedback, so that we can improve it in the future - though of course feedback now is also welcome as well.
adam at adamcaudill.com
> On Nov 26, 2014, at 9:01 PM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> 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
> Since some of the organisers read this list and this question may be relevant
> for other contributors as well I'll ask it here:
> 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.
> cryptography mailing list
> cryptography at randombit.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the cryptography