 Adam Caudill and Taylor Hornby will be presenting the underhanded crypto contest winners. Take the way, guys. Thank you so much. And thank you everybody for showing up today. So here we are at the end of the fifth annual underhanded crypto contest. Underhanded cryptography contest. Let's make that clear. So I am Adam Caudill, one of the co-founders of the contest here with Taylor Hornby. And Taylor, I will let you take it away. Cool. Thanks. So just in case you haven't heard about us, we've been doing this for five years. Basically the way it works is every year we ask you to send us your best ideas for cryptography backdoors, whether it's in the protocols or implementations or whatever as long as it has something to do with backdoors and something to do with cryptography, then we're going to be interested in it. And you really do want to send us your ideas because we hand out prizes every year. So why do we do this? Obviously we're derived from the underhanded C contest. And one of the things I really liked about the underhanded C contest was it's the perfect thing you can point to if someone says, oh, all these people have looked over this code and they haven't found any problems in it. So it must be okay. You can kind of point to the underhanded C contest and say, no, actually if someone's trying to hide mistakes in code, it can be actually quite hard to find them. And we're kind of the same thing for cryptography. So if a company is claiming their product is secure because they're using AS256 and all these secure primitives, no, that's actually not enough. You need to dive deeper and look at the protocol and look at the designs and look at the implementation and find the problems there. Another reason we do this is because I think once we start to collect a lot of examples of what people do when they try to put backdoors into things, we'll start to catch on to the patterns that people try to use to hide backdoors. And once we see enough examples, maybe we'll get better at finding actual intentional backdoors in crypto and practice. And my favorite reason for doing this is it's kind of like a playground where you can invent your own vulnerability. So imagine you're doing a security audit and you're chasing a vulnerability and it just turns out that by some accident the vulnerability isn't exploitable and you can't write it up in your audit report because it's not exploitable. Well, submit it to this contest because that would be a good backdoor. If it's something that could happen by accident, that's a great property of a backdoor because it's deniable. Yeah. So that's why we do this. So this year we were sponsored by the Zcash Foundation and NCC Group Cryptography Services. So just a little bit about our sponsors. The Zcash Foundation is a 501c3 non-profit supporting research and development for internet payments and privacy stuff. So they focus on Zcash, but I think their scope is a little broader than that. So if you work in that area, you might want to check out their biannual grants. They might be able to help you fund your work. NCC Group, if you haven't heard of them, they're one of the top firms doing security consulting, especially with their Cryptography Services division. They're really talented people. And before we get into the actual three submissions that we got this year, I want to give a really special thanks to J.P. for helping us judge again. He's been with us since the beginning. And to be honest, sometimes some of the entries are way above my level of understanding, so if it wasn't for his expertise, it would be hard to do this contest. So, okay, let's see who came in third. This is a bash script, James sent us. And basically what it is, is you're supposed to give it a bunch of files as command line arguments and what it's going to do is it's going to encrypt each file with a random password and then at the end, print out all the passwords so that you can save them and then decrypt your files later. But the way it does that is it's appending the passwords to a temporary file, which is fine. But then it reads the entire file full of passwords into an array. And so the password we want to use to encrypt this file is going to be the last element in the array. It's the last password that was generated. And what this code here in bold does is it's supposed to access the last element of the array, but of course it doesn't. It accesses one pass the last element and that means all the files are going to be basically encrypted with the empty string. So, trivially decryptable files. Moving on to second place, Ella Rose sent us a needs key agreement protocol. And the way this works is there's two public parameters called E and N. And so when Alice is generating her key pair, she just generates a random 256 bit number called X and that's her private key. And then to get her public key, she takes X, multiplies it by this huge number E, adds another random number R, which I won't tell you the details of, and then does that modulo N. And then that's her public key. Bob does the same thing to get a public and private key pair. And then when Alice and Bob come together and they want to agree on a shared secret, they basically, Alice will take her private key, multiply it with Bob's public key, and Bob will take his private key and multiply that with Alice's public key. And because of the way the sizes of all these numbers are tuned, if they just chop off everything except the first 256 bits, those 256 bits that are left will agree and they can use those as a key. So this is the backdoor key agreement scheme. Where's the backdoor? Well, the backdoor is in this parameter E here, and I'll explain how that works. So basically we're going to pick E to be special in some way. And the way that we're going to do that is, well the first idea, the simplest way to do this, is just pick E so that its multiplicative inverse is small, modulo N. And so we'll call it multiplicative inverse D. And if you have a small multiplicative inverse D, then you can just take Alice's public key, which is X, sorry, it's EY plus Z. So sorry, no, that's not it. It's EX plus R. And if you multiply that with D, the D and the E are going to cancel out because D is E's multiplicative inverse, mod N. And so what you're left with is X plus DR mod N. And now you can actually pick, you can pick E so that D is small enough so that X plus DR is less than N. So taking the mod is not doing anything. You actually have X plus DR. And then once you have X plus DR, you can further constrain E so that D has the property that X is less than E. And then once you have X plus DR, you just take that mod D, the DR turns into a zero and you just get X. So we've recovered Alice's private key. That's kind of too easy because like everybody in the world knows E, it's a public parameter of the crypto system. So we need to make this like a little bit harder for like other people to exploit. And the way that this works is instead of making E have a small multiplicative inverse mod N, you make it have a small multiplicative inverse mod N minus K, where K is some random number. And it turns out that if you pick the size of K, just right, then it's still true that if you multiply by D and then do mod D, you still get Alice's private key. So it still works. But it also, the contestant makes an argument that actually if you don't know K, if you don't know the secret K, then you can't actually use the back door. It's as hard as breaking RSA to use the back door. So yeah, I think that's pretty cool. Now on to the first place winner. This one is actually really simple, but it's kind of effective. So the idea is if you're going to do elliptic curve cryptography, then you ought to just use a standard curve that like people have researched and studied and like believe is like a good curve to use for elliptic curve crypto. But maybe someone might want to make a protocol where the curve itself is negotiated as part of the protocol. And obviously there are curves that aren't safe for use with elliptic curve crypto. So the protocol is going to need to check some properties of the curve to make sure that's secure. And what this submission does is it's basically saying you can have the protocol make a bunch of checks of properties of the curve that's checking for all of these properties that needs to have in order to be secure. But unless you're a cryptographer and you're familiar with elliptic curve crypto, you're probably not going to be aware of every single check that needs to be made. So you can just leave one of them out and then everybody who doesn't read obscure elliptic curve papers will not realize that the protocol is actually vulnerable to using a curve that's insecure. So yeah, that's the winner. So now that we've seen the entries, there are only three this year, but I'll talk a little bit about what our plans are for the future. So over the five years that we've been doing this, we've accumulated 32 backdoors that people have designed. And I think that's enough of a sample size that we can start to draw some general conclusions about what maybe we can classify backdoors according to certain techniques or something like that, or come up with some strategies to be able to detect them and things like that. And actually think that this would be a really good project for an undergraduate if they're doing a research project. So if you are an undergraduate or you know one who might be interested in looking over all of the entries we've received so far and still acknowledge out of that and writing a paper, definitely get in touch with us because I will provide as much support for that research as I can. And of course if you missed participating this year, we're going to be doing this again next year. Hopefully we'll get a little more entries next year, maybe some better prizes. So stay tuned for that. And before I wrap up, I just want to thank our sponsors, the Zcash Foundation and NCC Group cryptography services again because really the prizes are white people send entries. So yeah, thank you for your attention.