Encryption for Developers

hey everybody um thanks for rejoining us after uh lunch or besides boulder so we've had a little bit of a change of schedule unfortunately one of our speakers went um a little bit awol this afternoon um no worry though because we have um somebody else actually um here to uh deliver a short talk um so today we're gonna actually be having james um or punk coder if you're in the um discord channel um presenting um a talk that he's done a few times before i've seen it it's wonderful um on encryption for developers and what you need to know about encryption um as somebody who's uh writing code potentially um to give a little bit of background

james is a developer a security advocate whose biggest responsibility is leading developer security practices he sets the standards and procedures for how practice operates leads all client engagement efforts with regard to security he also takes the lead in making sure that company staff developers specifically are properly trained and following best practices with regard to application security so with that i'll let you take it away james fantastic all right so let's go ahead and start up the presentation and get a quick confirmation that you all can see this yep looks great all right fantastic today we're going to talk about encryption for developers or everything that you wanted to know about cryptography but we're afraid to ask

and really you know a little bit about me i you know do developer security i sit on the orange team for trimble um i have a mcpd mcpdea as well as the cissp i still try to do coding on a regular basis and i do a lot of speaking i think the next one that's coming up after this one uh will be nebraska code here in a couple months so let's talk about crypto and whenever i say crypto i mean cryptography not cryptocurrency so hold tight we've got a lot of stuff that we are going to cover in a very very short period of time um if there are any questions i will be more than happy to take some

questions in the discord channel following this but for the moment let's go ahead and dive right in okay so starting off if you've got no idea what cryptography is what it is simply put is the art of using mathematics to keep secrets secret we're going to use different various functions to produce a system that is very easy for some people to get the information out if they've got the key or hidden away for people who don't so uh why should developers care about it and furthermore why should secure security professionals care that developers care about it well many of the failures and security come from ignorance about cryptography we saw a great example earlier today

where you know we're doing these kind of secure communications across across student software but there's no security to protect that messaging going back and forth um you know the second part of that is improperly used cryptographies almost as bad as having no crypto at all um and we'll see some examples of this here in a little bit um the majority of information that developers know about cryptography is given to them really fourth or fifth hand um so in most cases your developers are getting told basically like you know you need to do encryption at rest and then the person who's telling them that walks away okay um and the second part of this really goes down to where okay so if we

aren't educating them as security professionals where are they getting this information from and generally speaking they're getting it from stack overflow and as we all know stack overflow does really bad stuff with cryptography now information exchange completely different uh situation they do a fantastic job of doing it and explaining it at such an academic level that it's almost impossible for a developer to consume so let's take a look at kind of the base portion of it and really dig into this subject okay so couple things to handle first encoding encoding is not encryption um and we see this used in places that is kind of ridiculous that we're still seeing this um you know kubernetes secrets docker

secrets are still encoded using basics before there's no no actual protection there you know um encryption really is the process of producing unreadable text through the use of keys and then hashing is a one-way function where we can feed something in it it becomes almost impossible to get it back out save for example with the use of rainbow tables okay so here's an example of the kind of stuff that you see as an appsec person looking into this so whenever we tell the developer we say hey you should definitely salt and hash your passwords um and so this developer and this came out of real code that i saw as part of a review they did exactly what they were told to

they salted and hashed the password um but there's a huge number of problems with this code first of all we've got you know we're running it through one iteration of sha-1 the salt is static salt and we're not sprinkling the salt in we're just appending it to the end so we've got a lot of things that are wrong with this in this space so one of the key pieces if you take away nothing else from this conversation i want you to take away these four things these are the four good ways the four only acceptable ways to store passwords okay and we'll dig into these as we go first one is the password based key

derivation function two or p d n p b k pbkdf2 so an impossible acronym that goes into this and it really goes through and it produces this process of doing the password and all this and so we've got the various pieces in here uh the prf which is usually a hashed hmac it's built in we've got the password that we're supplying we're including some salt that's cryptographically random and the key here is we have to remember that it's cryptographically random so as a developer you can't just go out to do the random library you actually have to go out and do the cryptographically strong random salt okay then we've got the number of iterations we go

the key to this is the more iterations we're doing the better and the key to this is the last one is the derivation and derived key length and this is what the n by product is and we want to make this sufficiently long so that we don't accidentally run into collisions now where does password-based key derivation function really shine it shines in areas where we've got kind of constrained environments for processing because this particular function doesn't use a lot of cpu to go through and pull these pieces out it actually functions very quickly um so makes it more uh applicable for things like use in the cloud for you know cloud-based applications um as compared

to some of the items that we're getting to talk to now the high point of this is also kind of the low point right because this is such a um intel password kind of non-intensive function it means that we can more easily spin up things to try and defeat it we'll take more a look at that more in the future the next one up is bcrypt um this is a password derivation function using blowfish that's memory locked so the key here is as we start stepping down through this you're going to start seeing ways that we lock this down and the further that we lock it down we're making it dependent on something on the system

and so from an attack standpoint what that's doing is it's actually making it more difficult because the ability to go through and brute force this now requires some combination of resources to produce a single output and that's really what we're looking for here so we've got decrypt it goes through we have cost salt and password right pretty simple stuff key is is that we want to make sure the we have the max number of iterations that we can that makes sense for your space now where this is going to be and you're going to see this is if you've got this on a device that's maybe uh memory constraint that will work out really well because it

helps to break it uh or helps to keep it structured in a mobile device or something like that um if you put this into the cloud it will also function very well the trick is is that you're going to have to make sure that you have enough memory to cover the number of people who are going to try and log in or register as part of the process script very similar place except for now we're not just locking to memory but we're also locking the cpu and that's key because the further we go up this change chain the more difficult it is for an attacker to go through and try and brute force those passwords

and so we've got this we've got our password we've got our salt we've got the cost which is a way for us to balance the cpu versus memory cost as part of this our block size our parallelization factor or how many cpus do we have to set off or threads do we have to set off to be able to calculate this process and then finally the output key length the last one that we're going to talk to this is the way you should be doing it and i say this because whenever we take a look at the numbers of what it takes to process we will see that this drops down significantly and makes our application

significantly more secure especially when we're talking about the password portion of it so argon 2 comes in a couple different flavors the one we're really going to want to dive into is argon 2i uh sorry 280 and it really locks it down to memory execution time and parallelism locked as far as we go across this okay so what does this look like if we take you know a simple laptop that you can go and buy at best buy um and actually run the numbers through this doing the first example that we saw of our developer you know we see that there's you know 38 000 mega hashes okay that's a lot of processing power we

can chunk through those password lists very quickly to test them but the further we go down through this once we get the password based key derivation function we're down to hundreds bcrypt has us in the hundreds s crypt has us in the thousands of kilohashes when we drop down to argon 2 we are in the thousands of hashes that is a significantly more structured way to handle this currently as far as i understand there is no way to speed up an argon 2 id hash breaking process with accelerated graphics cards and things like that okay but at the end of the day encryption is only as good as your keys so make sure that you're protecting them

accordingly great example of this is the capital one hack and we saw this a couple of years back but effectively what happened is we had old credentials on a waf that allowed to pivot into an et ec2 instance then switch and use that lateral movement to gain access to the metadata service if you are storing the keys for your encryption right next to where you are storing the data that is encrypted you are going to have a bad time this is going to end very poorly for you the end result they were able to say okay well we've got an encrypted bucket here we've got your encryption keys here well i'll just clone the buckets and unencrypt them and

then siphon off the data okay so the first part we're going to talk about for this is symmetric encryption symmetric encryption really refers to the ability to communicate encrypted using a single shared key now this works really well in the situation where you don't actually have to share that key if you've got inherent knowledge of it that works really well because if i'm encrypting something for myself i don't have to worry about that key leaking so going back in time the first one we're going to talk about really here is lucifer lucifer is des if you and i'm not going to go into a whole bunch about this but if you see des in code base you need

to run as a developer this is a horrible thing you'll see and it's implementations of it get really really strange i've seen uh dez implemented on android devices and if you are a pen tester and you see des implemented on a uh android device or on an iot device you are in luck because you have the the world is open to you um because the key is only 48 bits you can easily brute force it in a very very short amount of time yeah we go through i talked a little bit about dez um was fully broken in 1999 and you can uh hit the entire space in 22 hours and 15 minutes at this point it's

not even that long okay um triple beds if we go through we see triple des in code we need to start extracting it it's considered extremely weak since the entire calculated key set fits into a one terabyte drive okay the rc family now this is kind of mixed back and forth and there's problems with uh these because they're actually licensed technology um some of the attacks that we see against wep are based off of these the fact that these individual cryptographic algorithms are no longer strong so the rc family you got to be kind of careful with how you use it but here is the key if you're writing code and you are setting up applications that you want to

be secure and you need it strong symmetric key aes is your winner okay comes in block sizes of 128 192 or 256 bits as part of this you will need to specify an initialization vector this is a matrix of values that allows it to start randomly at a various point and then do the decryption or do the encryption so that whenever you encrypt the same value multiple times you get random data out now one of the interesting things that i've seen developers do is if they don't understand how the initialization vector works they'll use iv.net and what that means is it turns the initialization vector into a bunch of zeros so you will get the same data

every single time and whenever you do that it allows the attacker or the ability to start guessing at some of the stuff as we will see here in a few minutes okay so whenever we talk about aes there are five modes that we have we have electronic code book method cipher block chaining cipher feedback output feedback and counter these all have individual uses as part of this um electronic code book is the main one that we'll talk about as kind of being weak because it's severely weak and essentially what it does is it encrypts a block of text using the same key the same way every single time this should not be used for anything but the absolute

smallest of messages okay uh cipher block chaining works really well if you are doing encryption in a way where you need to do random seeking and because the way that it's set up is the encryption portion of it is single threaded which means as you're writing it is slow to write but can be read fast and can be randomly s moved to a random point if you know where in the memory you want to go cipher feedback can't be paralyzed the decryption of it however can be so whenever we're going this is another one where we can go through and allow random seeking as part of this process last one is encryption uh output feedback which means we're taking the

output of each block and moving it into the next one as we're going along this means that you have uh if at some point portion of the message is captured if it does not have the information that came before it it is absolutely worthless so if you've got long living streams of data where you have to have these pieces in place you can use these tools to get through it does not allow for random reads or writes and the last one is counter um this encryption method works well in situations where you have to have fast right fast read and can be used to paralyze the data across multiple threads allowing you to get those random reads

okay um here's the reason we don't use electronic code book mode if we have for example a password that goes through here and we notice if we change just that very s in the very very middle from an upper case to the lower case we see something very interesting happen um on both sides of that block that has changed we have the exact same values now as an attacker you can go through and you can see this information in such a way that you can actually go and if i only need to modify a certain portion of it i can try and take guesses of it and pull from something that i know to be

good and stick it into those blocks and i may get lucky enough to get stuff to work okay one quick second all right so now we're moving on to asymmetric encryption asymmetric encryption is the situation where we need to have two different people who have a secret and don't want to share their secrets with other people to get their first secret back and forth i guess that makes sense um think of this like a mailbox so the idea is is that whenever i want to send something to somebody i take it i wrap it up in an envelope that has that person's name on it and i take it and i stick it in the

mailbox now theoretically once it gets to the other end the only person who can legally open that is bob because bob's name is on that envelope we do the similar thing but it's just with math right so the idea is that whenever i send bob a message i'm going to encrypt it with bob's public key and the text that i want to send it to him he gets cipher text in order for bob to decrypt that he needs the site for text and his private key as well as his password to unlock that private key so this all was made possible through the use through the diffie-hellman key exchange and if you haven't ever had really a good dive into

this um you should definitely take a look at it there's thousands of videos on online that do a far better job than i will do in the short amount of time that i have to talk to you but it's a way for us to exchange information back and forth between two people without giving up a secret it is fundamentally the basis for most of uh asymmetric encryption okay so rsa rsa is fundamentally what we know across the board mostly as the mainly used asymmetric encryption algorithm it relies on the fact that we that factoring very very large primes is challenging um because of this the process of generating these keys is very slow requires a lot

of entropy in order to do that entropy being the uh the randomness assigned to it um and so there are some places if you have to generate large amounts of uh of rsa keys then you'll need to offload some of that functionality to something like a hardware security module in order to make that work but the key is here was what we're looking for um the bit rates that are associated with it are important for us to understand how secure something will be going as we move into the future okay um right now a 256 bit rsa token can be broken in about 35 minutes uh 124 is still the minimum considered to be secure that's really

starting to fade out generally speaking 2048 is the space where most people consider the trade-off between the time to use it as well as the time to generate it is kind of the good point it gives you a decent amount of security but if you're looking at forward secure forward privacy making something secure in the future 4096 is where you want to go um whenever we talk about quantum encrypt uh quantum functionality breaking cryptography this is what they're talking about because fundamentally quantum affects the ability for us to to factor large primes and because of that that presents that weakness to us okay um there is an interesting piece that we need to step out of here

there is an oracle attack that goes into this called oaep is the codebook issue that relates to rsa i'm not going to dive into it here there are lots of great videos but if this is something that you're looking at it's definitely worth diving into um the next one that we talk about is elliptic curve an elliptic curve really does a good job of generating some very very secure very fast public private key cryptography now there's a huge caveat here due to the fact that some of the curves that were introduced by the united states government are considered weak um you need to stay clear of certain of them now whether they are actually weak or not that's questionable

but the perception is is that if you're in this situation you probably just want to avoid them all together these are also potentially weakened through the future of quantum computing but there are some things that people are doing to tweak that to make it a little bit more secure here are the weak elliptic curves that you should generally avoid um again there's a lot of political reasons about this especially if you're dealing with certain other countries that you'll want to avoid them just so you don't have to answer questions more than anything else yeah cryptography and i'll cover this super quick um and the quantum thread this has been a hot topic for a lot of years going forward

um in reality it's not really that big of a deal we've known that this is the quantum edge has been coming since the 1970s people have been working to do some really good research to keep this kind of at bay um and some of the algorithms that we've had have been around for 20 plus years really being beaten on them and moving them to the next level um if you want to kind of defect uh protect yourself against this we've got uh perfect forward secrecy um the openquantumsafe.org has a fantastic set of tools that are built into open ssl with newer versions that allow you to integrate uh lattice and other types of quantum resistant

cryptography which will give you an additional uh secrecy going forward so if you have to worry about your data being lost over a long period of time and with that that's it i hope you had a good time i hope i gave you enough information for you to go off and kind of find new stuff um if there are any questions i will be more than happy to answer them in the channel thank you