Cryptography Pitfalls

all right thanks everybody so as the slide says this is cryptography pitfalls and my name is John Downey if you are interested in my slides I've already tweeted a link to them so you can check out my Twitter that's a trick to try to get you to follow me on Twitter but so the basis for this talk like why I've gone around and given it to a couple places is because I see developers making the same mistakes over and over again when trying to work with cryptography so this is really a cautionary tale I like to base like I'm a real big fan of listening to other people talk about failures because I think we can learn a

lot from that so I wanted this to be grounded in what real things like real places where stuff failed and I want I want people to kind of take away is like oh like I remember this from this talk maybe I'm in over my head and I should get some professional help so that's that's my goal in kind of a little bit of context why I've been giving this I do not live in Philadelphia this is actually my very first trip to Philadelphia I live in Chicago but I'm very happy to be here really quick so I work at Braintree where I leave the security team the only reason this is kind of important is just to give you a

little bit of a background brain tree if you're not familiar with that helps businesses take payments like credit cards we obviously deal with a lot of crypto around that also more importantly Braintree was acquired by PayPal a couple years ago so I need to say this if your work for a big public company you'll recognize this statement these are my views don't hold them against my employer so I want to quickly give him an overview look what do we expect out of mine crypto why are we even using it and when we think about cryptography were usually thinking about three purposes the first ones confidentiality and that is when I send a message I expect it to be kept secret between me

and the time there's seesee anybody in the middle eavesdropping shouldn't be able to decrypt the message this is really like the thing when you say cryptography everybody sort of gets it and jumps to this one next ones authentication or integrity protection when you're sending a message you expect the message not to have been modified in transmission by anybody so that the other ink can kind of validate that this message hasn't been modified in transit that's important because you could be sending things like military orders and you don't want those military orders to get modified in transit and then the last one is identification this is like who sent the message you often see this combined with authentication in the form

of digital signatures you know John signed this message and it hasn't been modified since John censored and cryptography itself at least in the modern sense is a rigorous science it's a lot of the times it's based on hard math problems and their math problems we consider hard on classical computers like laptops and even today's supercomputers are all still what we would think of as a classical computer you can read that as not a quantum computer I do have a little bit at the end about quantum computers and how its kind of leaking into our current thinking so it's rigorous science-based I met thrones like factoring large numbers of did their base primes which you may know is the problem behind RSA

and so we're really doing is we're betting on no major advancements and I had their mathematics or computing that's what cryptography is doing and like any science crypto should be peer-reviewed you know we we've been really really good about getting into the heads I righted the whole don't design your own crypto like I think that's been like car occulted enough that most people can kind of repeat that and understand it but we also need to make sure that don't design your own crypto also carries over until like don't implement your own crypto so sometimes you'll see people say well I implemented AES myself and code that I wrote I didn't design a DES and there

are still a lot of really subtle problems that are gonna come up and bite you in those cases next thing we you know we think of things like peer cops principle which is that system should be completely public in its information except for the key I should be able to tell you entirely how our encryption works and it should be no less secure as long as I don't have to as long as I don't also give you the cue that's kind of the ideal in modern crypto we also think of this is like combating security through obscurity crypto itself is very strong I don't expect to wake up and read in the like ARS technica and hacker

news or whatever that AES is broken however the I wouldn't be surprised if I woke up and said something to the effect of the way OpenSSL influence AES in this specific way that's broken and it's cash traffic go update your open SSL that I expect to happen and we do occasionally see things along those lines but like anything in security a system is really fragile most fragile at its intersections so the places where things have to kind of come together the joints between the the various primitives and predators often kind of get misused and misunderstood so a lot of times when we see break breaks in crypto we see it at these seams between the different

primitives and unfortunately the the missteps are really catastrophic and lastly I accounted I'll read this to you real quick because I think it's important you've probably seen the door to a bank vault at least in the movies you know 10 inch thick hardened steel with huge bolts to lock it in place it certainly looks impressive we often find the digital equivalent of such a vault door installed in a tent the people standing around it are arguing over how thick the door should be rather than spending their time looking at the tent this is from a book called cryptography engineering by a bunch of rather famous photographers including Bruce Schneier and what I kind of think they're getting

at is sort of you know you'll it's not it's not hard to find a conversation among crypto or security people where they'll be like we should be using 128-bit key no it must be a 256 bit key and totally ignoring the fact that the system that they're talking about has like really easy sequel injection and like Floyd and cross-site scripting and stuff like that so you know just like totally ignoring the weak parts of the system and anything if you take anything away from this presentation this is kind of like the slide where it's like oh okay if I'm doing this here's the thing so for data in transit use TLS we used to call this as a cell now I would call it

TLS for a variety of reasons use SSH or some kind of VPN data in transit means data going across a network or a wire for data at rest use GPG this data at rest means on a hard drive on some kind of flash drive up in the cloud like s3 if you needed to be encrypted at rest use that use GPG if you need to sign something for right now use GPG though like those are kind of recommendations if you can't fit your problem into one of these three try to rework it until you can because you'll save yourself a lot of headaches if you can and ultimately I like to talk about avoiding low-level libraries I liken

this to giving developers a bucket of razor blades and asking them to build a saw you're really bound to kind of hurt yourself if you don't know exactly what you're doing low-level libraries things like open SSL PI crypto and bouncy castle these work at too low a level they kind of give you these really basic primitive building blocks and expect you to build something useful out of them instead using a high level library like salt or a low sodium or keys are from Google these you know you can find these with bindings to every single language under the Sun so they're really easy to kind of pick up I did however promise some pitfalls so that's what we're going

to get to next first one being random number generation so random numbers are really important we used them for encryption keys API keys session tokens password reset tokens the you know everywhere and our systems really do rely on us the first pitfall is not using a cryptographically strong random number generator there is a paper presented the 2012 usenix conference called I forgot your password randomness attacks against PHP applications where they surveyed a bunch of PHP applications and found some where they were just using the built in Mersin twister kind of built in PHP random number generator to generate password reset tokens and through a lot of analysis they were able to guess Password Reset tokens sent to email to a

user before without ever being involved in that transaction so they're able to predict the password reset token and then use it to reset a password and that is because this these this PHP systems we're not using crypto strong Reena member jayn errors when they should have and this is just a visual example of what I'm talking about so the one on the left was generated using I not crypto strong random number generator if you look you can kind of see there's a wavy pattern to it that's exactly the thing you don't want in your random data you don't want patterns and then the system or the graph on the drawing on the right was just a completely random

dump of data the next one using broker and owner generators unfortunately it seems this is becoming like everywhere every systems got their day in the Sun and so very recently GPG had one that had been in there for I think like 12 years Debian had their famous one this was 2006 to 2008 if you're not familiar with this in Debian this line was comped it out out of the Debian packages of open SSL for about two years and this line was coming out in two places and if you don't know what it does that's fine what it was doing it was mixing in random data from the operating system and to openness the cells random number

generator which was important and it was coming down in the two places and because Debian is sort of a parent distribution for a lot of other distributions it made its way into a bun too and Knoppix and tons of other places and for two years this meant the random number generator for open SSL on debian based systems was completely broken and this sort of goes to show that bad cryptography often looks a lot like good cryptography and you don't really know it until someone comes in breaks your stuff this was the commit message it went in under don't add uninitialized data to the random number generator this stops Bell growing from giving error messages and unrelated

code if you're not familiar bow Brian helps find memory failures or memory problems in C programs so is essentially trying to it's a compiler warning I wasn't an error it was just a warning and the real thing that gets me is that they ran this by V open SSL mailing list and they're like hey here's this thing and nobody like yelled stop and unfortunately meant that every SSL key and SSH key generator on these systems were completely broken this is that line today I went back and kind of dug up what what they had done with the line so and open SSL they have these giant comments on either side of it saying please don't remove this it's

critical to the security of the system but as I said every system seems to get have been getting it today this one was from Android Android the base operating system remember janitor was broken for a number of years this was found out because folks were using Bitcoin applications on their Android phones and their Bitcoin wallets are being stolen and it was kind of traced back to us juniper this was around this time last year it had been discovered that the constants in the random number generator and a lot of their appliances they didn't know where those came from and unfortunately they're using a random number generator that has known to be back back durable in fact it was the

dual EC ran in our junior they even years before Ed Snowden released so documents around this these higher first account said and presented this at the 2007 crypto conference hey this this standard is totally back durable no one should use it but they were and then lastly FreeBSD had their own this fortunately never made it into a released version but it was broken in the current branch for around four months because they were in the middle of refactoring the Raymond our generator last one not using random data when it's required this one bit Sony so Sony was using an algorithm called the elliptic curve digital signature algorithm which like it's non elliptic curve variance has a parameter K and K has to be

uniformly random for every signature it turns out they were using a constant value and through a little algebra manipulation you can actually use this to get the private key that signs the data from this I believe they then went around and use that to load home it's also kind of fun though so really vital user crypto strong random number generator when it's needed if you're on unix-like system read from Debbie random there's some debate and consternation around this one but I'm firmly and be read just read from Debbie random camp on Windows you have random number generator and net encryption random in your base standard library next talk about a little bit about hash functions you'll often hear hash

functions called a fingerprint and they really have a lot of similarities both are one way so when you when you look at a fingerprint on like a glass like say I grabbed a glass and you kind of look at it later but I ain't kind of fingerprint database you wouldn't be able to know anything about that like just the fingerprint itself doesn't give you any information so it's not reversible without having someone had fingerprint database and ideally no two people should have the same fingerprints we think of this as a hash function no two inputs should yield the same output in an ideal world the first one using old weak algorithms this will unfortunately be a little bit of a common one that we

had touched on today this was in 2008 these researchers used a whole bunch of ps3s to have a cluster configuration to predict the the Hat or the hash function output of md5 when it came to a digital certificate so something that they got from a CA such that they're able to match with the CAS output was gonna be on the when they sign the certificate they're able to match what the signature was gonna come out to but on their own imports using previously at that point unknown problems with md5 and it took a lot of computation which is why they used the ps3s but this was sort of like the death knell for md5 in the CA

industry then on its way out but people were obviously still using it so they use this to give themself their own in intermediate CA certificate as a demo the next one flamed the malware that you know it's kind of well known now for being infecting confused systems in iran when the when the researchers kind of like reversed this they found previously unknown problems with md5 in that malware that had been used to exploit this showing that there was probably some kind of intelligence service at work with this because they burned one of their md5 exploits or potentially one of their md5 exploits by putting in this malware and then lastly in the last this was October

2015 there was a paper published called free start collisions in full sha-1 this doesn't mean sha-1 is 100% broken but it means like the writing's on the wall stop using sha-1 this definitely accelerated the CA industry's move off of sha-1 they had been doing it for a while but this cab was used as justification for not slowing down and if maybe moving faster next one this one is just a fun one United States Cyber Command that's their logo on the inside gold ring there's some simulator and numbers and this is it blown up so it turns out this is a hash digest it's a half day just of their mission statement using md5 so this is like cryptography

as a design aesthetic I'm not really sure I have no idea why they used in b5 for this because it was well known that you shouldn't at that point and I think person just didn't care because they're just going into a logo but it's funny the next ones misunderstanding you know what do we mean by a signature versus a checksum so it took a while for me to find something but this is a you know we kind of you've been around a while you're pretty used to seeing like a directory listing on like an FTP server or something and invariably there's always this like md5 sums or sha-1 sums file which contains all the files in that directory

and then they're associated checksum and you know this this is still pretty common today but sometimes will happen here in the misconception is that when you download the file you download that that sha sums file and you compare them you think ah the software hasn't been modified that checksum is matched and really you should be thinking ah the software just didn't get corrupted during download which is really what they're going for these aren't digitally signed we're like GPG or anything so if someone goes and modifies one of these carbon files they might as well just update the sha-1 sums file as well which has happened to you know open-source software in the past the last one is a length extension

attack I'm not going to go super in-depth into this one because it gets kind of complicated very quickly but it is fascinating so I recommend you go and look more into it later if you're interested in the gist of what we're getting at when we're looking at these length extension attacks is that the people invariably wanted a Mac or a message authentication code and a Mac is an algorithm which takes some kind of shared key in some kind of value and then produces an output we call the tag the tag is just this thing that you send along with the value and the other end can just validate that the value wasn't changed in transit it's a symmetric

authentication algorithm the naive way to think about this that people will construct these is they'll just append a key and some value and run it through shots of 56 it's still free to comment still see it today and this is vulnerable to a length extension attack which the gist of it is if I generate my signature using this I can then sign this new thing knowing not knowing the secrets not knowing the original value but knowing what I want to append and in the current signature so this this is called a length extension attack it's based on the have some features or some fundamentals of how these hash algorithms work so I recommend going investigating more if you're interested

what they should have done in this case is used as I said Mac so there's an H Mac which is you built up using hash functions that operates like this so this this one isn't just a theoretical vulnerability Flickr had this so these folks reported it and they had to iterate their API because they had those vulnerability and then visa actually released a new payments API to have this vulnerability in it to their credit they very quickly fix this but it even goes kind of to show that today an organization with the InfoSec resources such as visa people are still making this this simple mistake that we know about so yeah if you need a fingerprint you

shot 56 I do know that sha-3 is around there's a lot of debates around using it I'm not ready to jump on that bandwagon I still recommend shots with you six two people if you need a signature a Mac H Mac is a really good choice with shots of ado six stop using md5 meaning like if you have a system that uses md5 you should really be making a plan to get off of that and don't use sha-1 and new projects should probably be thinking about phasing moving away from it definitely if the system you're using it in requires collision resistance as that's the first thing to go next up is password storage but I'm skipping that

because this is a conference of security people and there wasn't really anything new I hope everybody here is sort of you know in the camp of use be Crips or s crypt or whatever you can read more the only thing that was in here that was different than just password storage was something that I've already blogged about and then it's already been repo it's been reposted to the b-sides fili blog so it is a blog I wrote all don't wait to fix your password storage and talks about method a method that I recommend to people who find themselves with less than ideal password storage techniques so you can go check those links out and that was to save time so

we can talk about contact computers later ciphers once again old weak albums kind of rears its ugly head breaking ciphers with Copacabana this was presented at a crypto conference in 2006 and even then they they kind of looked at they could build a specialized piece of hardware for less than ten thousand that ten thousand dollars that could break you know digital des the digital sorry the the des algorithm in basically no appreciable amount of time so people really shouldn't be using des even at this point in 2006 it been replaced by AES and triple des but yeah I still kind of occasionally run into a system where they're still using des it's because they have like

a terabyte worth of data that was encrypted with DES and they don't know what to do about it it's totally broken you can't rely on it for any security this probably cost like a dollar on Amazon to breakdown so I really have to get off at the next one weaknesses in the scheduling algorithm of rc4 this was presented in 2001 it was kind of like saying hey we see the rc4 is not this really ideal thing and yet even like up until like two years ago people were still using rc4 and their TLS configurations because it was the only recommended way to combat the beast attack that everybody was so scared of it actually took a different paper in

2015 where they really just kind of hammered in that rc4 is broken and things like TLS to get people to finally move off it and you get vulnerability scanners like Qualis to start flying as a vulnerability next up using ECB for block ciphers quick refresher on block ciphers AES is a block cipher and what block ciphers are is a pair of functions there's an encryption and a decrypt function both of them take a key in AES cases the keys 128 192 or 256 bits long and then they both take 128-bit value and the encrypt it's the plain text and the decrypt it's the ciphertext and then you kind of swap them the problem here is most people don't

have 128 bits of data that they want to encrypt their data is typically a lot wide so the you know when you're kind of thinking through this well what am I going to do a natural thing that people sometimes will jump to is I know I'll just take it hundred 20 bits at a time or 16 bytes at a time and loop over it and just encrypt each thing they would not be alone in this this is actually a formalized method it's called ECB or electronic codebook mode and this is unfortunately very common and unfortunately very broken one of the reasons it's broken among others is that if there's any pattern in the underlying data that pattern is going to shine

straight through like a beacon so for example this is my company's logo and then my company's logo and with ECB mode the pattern shines straight through this is certainly not the only problem with it but this is the one that's sort of like people remember because it's visual and have oh yeah that's a problem you'll sometimes see this without tux the Linux penguin it's also pretty common but I wanted to make my own ideally when we approve something we want something that's at the bottom where it's just garbage you don't know what they're what they're trying to tell you the last one is not using authenticated encryption so what we mean by this is that back in the beginning when we

talked about confidentiality and we talked about authentication we now know after lots of research and study that you actually can't have confidentiality unless you also have integrity and unfortunately for many years the algorithms we used for encryption didn't provide only provide a confidentiality and not also integrity if you're using an hour and provides both that's called authenticated encryption and here are some problems if you're not using authenticated encryption there this is a very very famous paper presented in 2002 this has been the underlying paper that has basically spawned the issues in Tila a bunch of issues in TLS where Serge viognier talked about hey how TLS used its CBC mode ciphers incorrectly and how that was going to cause problems and

people basically took this paper and have just basically been finding different places where they can attack it in TLS for a couple years so this was beast poodle and then I think lucky thirteen and one other so the this has not been fixed until very recently TLS one three will finally fix the core problem of this even though it's been known for so long so as I mentioned practical padding Oracle tax this was the Beast attack from 2010 and this was just straight up implementing surge Vadnais attack Apple they had a flaw and I messages that allows you to do some interesting things with iMessage attachments once again because they weren't using authenticated encryption throughout the system this one I only

include the paper because I thought it was a very interesting title this is that Apple Capel paper excuse me dance on the lip of the volcano chosen ciphertext attack on a flying message the professor behind this Matthew Green said that he jokes that like he's probably not gonna like grad students name their papers anymore but this is a fun name and I you know I'd say I think the security professionals really should take a lot of the blame for this or should take more of the blame than we're willing to we basically have created this world of hurt for developers by essentially giving people so many options as you know developers especially for both developers and

security people we love to give people options and so behind this this is the PI crypt of documentation for AES and the first thing it has you do is you need to choose what cipher mode you want to use you shouldn't ever give anyone that choice you should pick a good cipher mode and use that so there's a bunch of cipher modes none of which are authenticated cipher modes and then the example uses output feedback mode which no system uses that I've ever heard of it's just sort of like one of those things where like in the 90s people are like oh yeah this is another way we can do it and I got Wikipedia page and so

occasionally you'll see it implemented and crypto libraries so definitely prefer the box secret box styles algorithms from live sodium this is like it's pre done authenticated encryption it's well understood it's you know it's very good there are a lot of different way systems that now implement this stop using DES stop building your own on top of AES which is so so popular and then stop encrypting without protecting the integrity also so stop using an authenticated encryption so I know someone in the audience is probably thinking I work in a regulated industry I have to use a yes so do I so if you do have to use AES for a variety of different reasons don't use it in ECB

mode be sure to use authenticated encryption so GCM is sort of like the go-to right now authenticated encryption mode for AES and then verify the tag Mak first and then you still have tons of problems that you may mess up in a critical way so just depending on the system may be a good opportunity to hire professional next up talk a little bit about TLS everybody's favorite whipping boy so the first problem here not verifying the certificate chain or hostname there's a paper from 2012 the most dangerous code in the world validating SSL certificates and non browser software in this paper they they surveyed a bunch of like iPhone and Android apps as well as like client

libraries for server-side stuff things that word had to do SSL but weren't browsers and they found out it was pretty bad so this is a really interesting read very humbling this you know is something that you'll occasionally still run into a developer who will turn off SSL verification in development mode and that code just gets checked in and goes straight to production without ever changing I just include this in here's a little trick break thought this was kind of funny there's you know this sort of kind of leans into the Internet of Things Wave that everybody seems to be going into right now we have an internet of things that probably aren't validating SSL include outdated versions of OpenSSL

in them and things like that next talk briefly about not validating the certificate chain so I stole this from a blog I really should have I forgot to put the blog post in there but the way the you can kind of think about certificate chain checking is you trust Captain Picard because he's Captain Picard you everybody trust Captain Picard and he's sort of like the civilian authority but you don't trust ensign Tony why would you he's a redshirt and that's sort of like the the server certificate but Katherine Burkhart trust George enjoy the parts trust in Santoni therefore you have this chain of trust and you can kind of you know validate that all the way down all right and so

that's great you've validated that you trust the certificates but that doesn't that doesn't mean that you've validated who that certificate it is so that leads us into hostname verification I kind of think of this as I went to a store one time and the I handed the checkout person my credit card and they're like I'm also gonna need to see some ID so I handed them an ID but I didn't realize I had my wife's ID in my wallet also and they just looked at it didn't even validate the names on the two things and just hand me my ID back that's not that's very similar to not validating the hostname so in this case you're

handed a valid SSL Certificates and it chains correctly and the signature is good but you don't check who it's named for so they could have just gotten a superior from like Watson crypt or whoever for free this was one of the other vulnerabilities that they analyzed in the paper this was pretty common so anybody would just go get a free certificate and it would you could man in the middle of their connections so frozen a verification check that you got the certificate you intended to connect to the problem here and why it's sort of done a little bit less often than you would hope is the host name verification it's protocol dependent meaning it's different for HTTP then for like SMTP

versus like FTP s and open SSL thus doesn't have it built in because it's protocol dependent and open SSL is protocol I have Gnostic so you you then have to lean on something like a Curt Lib curl or something that implements the various protocols this is a problem where if your SSL library just implements its own HTTP parsing on top of open SSL which rust had this in very recently you just totally skip the hostname verification part cuz you think OpenSSL is doing it next misconfigured server settings I blinked out the name to protect the innocent here or not so interesting I guess but this was a government website in Europe and what happened so Qualis runs us

salt labs which is an amazing site to check out and they this this server got an F you should go check out your own sites because it's very eye-opening to check out not just your main site that one's probably pretty good but what about all your like you know the Nagios and the muna and all the other like site instances that have been set up over the years so SSL labs excellent resource highly recommend that if you don't want people to know how bad you are you can check a little box saying don't put this in the public results for things behind a firewall so you have to get onto like the jump box into the production

infrastructure for like internal services there's test us to sell that sh which is a bash script which scripts open us to sell to test a bunch of stuff is very very similar to SSL labs but you can run it yourself behind a firewall highly recommend that one as well if you don't know what SSL settings UV or TLS saying is you should be using your server Mozilla has you covered they put up the SSL configure generator you just drop in you're like I'm using engine X with this open SSL and then they give you a bunch of recommended settings last one using a broken library we're all familiar with heartbleed I hope so horribly broken library the you

know I don't want to get on a soapbox about dependency management but I'm sure in the next year or two we will still here by a system busted because it was or someone popped because they're using heartbleed vulnerability ting the the SSL handshake correctly and that caused that was in OS X and iOS for a while the the problem is we lean a lot on these libraries and for good reason you know we want to trust that the libraries doing it correctly unfortunately we've had a huge rash of these libraries not doing the right thing sometimes so lean on them but also just give them a good double check there was one that actually like broke well I think it was AF

networking for iOS broke their SSL verification and like an intermediate version so it was good then they broke it for a while then it was good again set up automated tests if this really matters to you and you can use bad ssl calm as an example of like all the various ways SSL can can be bad next talk just briefly about trust so raise your hand if you've ever seen this line before all right now keep your hand up if you validated the fingerprint before you type yes so I thought me too so what this is is that SSH uses a system of trust called tofu or trust on first use and sort of SSH saying I got a

lot of fancy math that can check all this these signatures but I need you to do it first because I don't ship with any trust chains and you're kind of saying okay SSH I got you back this one's good remember that for later and if that trust chain ever breaks then SSH was like hey you wanted me to tell you and that trust chain was broken here it is and the solution here unfortunately if you like Google this and go to stack overflow is usually like RM RF the known host file instead you should really like surgically just remove that one line because typically this is like I reinstalled the system or some system came up with sharing the IP address of a

previous one next this is for dramatic effect me scrolling through the list of all the CAS that were shipping by default in Firefox as of like six months ago and this have is sort of a like hey do you want D know all these companies do you trust them do you kind of like what no that they're doing good hiring good firing you know could clean up all these things they all are audited extensively through the web audit standard but even that there was two CAS or really one CA think it was low sign in China that sort of found that they were like doing all kinds of nasty stuff it should not have been doing like

backdating SSL certificates to get around rules and just like doing all kinds of really bad stuff and then they weren't reporting things like we acquired another CA had been doing the same thing for them - that was start calm so if you're using wool Steiner start calm switch to a different one because they're about to be delisted by Google and Mozilla and a bunch of others or they're about to be implicitly not trusted or explicitly not trusted rather and they're in here so yay you do have a little bit of freedom and an option one thing is called certificate pinning so certificate pinning is where you can't explicitly lay out how you want your trust chains

to work this works least in browsers there's something called the public key pinning standard which is starting to gain some traction works kind of like strict Transport Security and that the first time you go to the page that it's a header that gets sent down and then the browser kind of makes note of it and then goes back later and it forces it so this is something interesting if you really do need the Canada guarantees check out public key pinning one thing denotes is that it will not stop if a company hasn't or or an attacker has installed a root CA on the system and uses that to like generate a certificate from their installed root CA this will

just blow right by and totally ignore your pins important ads because that's how like all these all these corporate environments have man-in-the-middle they're their employee traffic so if they broke that they would break a huge chunk of their customers that often people were like why and then when you think about you're like oh I understand why no so think about what organizations you really trust investigate certificate pinning in your apps if it's important to you and then lastly I want to talk just ever so briefly about quantum computers so we every five years we're like oh it's ten twenty years away and I think those 10 20 years is starting to really really kind of you

know writing's on the wall once again that it's going to happen sooner rather than later they're a bunch of companies d-wave is sort of marketing sort of actually getting to something but we what we do know is that people are banking on contributors come there are intelligence agencies doing mass traffic you know scooping up massive amounts of traffic and then storing the way in large hard drives and mountains so that in 20 years when they do have a quantum computer they can go back and decrypt them that is a reality we're pretty certain that's happening so the pitfall here is assuming current crypto will last forever and the reason we can't really assume that is because

of this paper published in 1997 by Peter shor this is what gives practical cryptographers nightmares and the paper was polynomial time algorithms for prime factorization and discrete logarithms on a quantum computer if you stayed you cryptography for a little bit but haven't seen this you might think to yourself prime factorization that's RSA discrete logarithms that's basically everything else you know you know e CDH Diffie a finite field diffie-hellman all the public key encryption systems we use are theoretically breakable in polynomial time on a quantum computer of a sufficient size it's pretty scary so we know that this is an eventualities most likely and google very recently did an experiment although they did end it after a year so they turned it or they

ended after a couple months they turned on and chrome when you talk to Google servers some percentage of users will in addition to getting and they looked a curve diffie-hellman key exchange also got a quantum computer a quantum resistant algorithm key exchange on top of that so they they picked one of the quantum algorithms that have shown promise at the time and they implemented that and although it balloons the packet size so like your key exchange you know gets quite a bit larger they said that they had a hundred percent coverage like they didn't see a need downplay in traffic like people's traffic didn't die in the middle because of some weird proxy which is good that's kind of what

they're going for here but it's very important they they did not want this to become like a de facto standard but what this did is it layered the quantum post quantum algorithm on top of it in such a way that you at least had the elliptic curve diffie-hellman strength and then if you this algorithm is actually quantum resistance then you also got that strength so this traffic theoretically would not be decrypted even indirect consequence here so follow the post quantum crypto discussion but stay away from this for a while because the industry is nowhere near the standards but there's an active group working on this trying to figure out what the best best things to use and then the last

thing is hope researchers are moving fast enough all right it is finally over if you're interested in this stanford runs with free crypto class on Coursera which is excellent the part two to this class is I like to describe like the big foot of Coursera classes they like every couple months low announced that it's going to be in six months and then that time rolls around and like I've gotten the course has started and then stopped emails like I've gotten hoarse surveys like that the class seems to never be never going to happen but the part one classes is really good math on our crypto challenges from now on crypto piles this is sort of coming from a

developer standpoint of writing code that will break these algorithms and these kind of things through a bunch of different increasingly harder problems if you're looking for code challenges I think this one's really excellent and that as I have questions and remember I tweeted a link to the side so if you're interested in the slide so you can find it on Twitter you can follow me while you're on my profile page I will take questions if there are any all right thank you you