 Alright. Welcome back everybody. Next up please welcome Steve who will be speaking about EasyPakeOven. I'm Steve. You may know me as Scoobs. Thank you for coming to my talk. So, a quick overview of my talk. It's going to be, you know, what, why, which, password, KDFs, APIs, and HSM's secret salt and recovery. So, what is a PAKE? A PAKE is a password, key, this always happens in like the first five minutes. I always get super nervous. Anyways, whew. Anyway, so a password authenticated key exchange is just that, it's a key exchange that has a password involved such that anyone trying to do any like malicious attacks or anything like that gains nothing from it. It's a zero knowledge proof and the only thing that leaks is yes or no for whether your password was correct or wrong. It also has, there's two different types of PAKES. Balance and unbalance sometimes it's called symmetric and asymmetric or augmented. So a balanced PAKE is where it's peer to peer. So, sorry. So a balanced PAKE is where you're peer to peer. So this is like two people that have a shared low entropy key such as like a short password or something that you pre-arranged or whatever. You can do a key exchange and it can be secure. The other way, the augmented asymmetric unbalanced way is a server client. So the server has a password and the client has a password and the server has a verifier that, so the verifier it can't be used as a way to authenticate to the server. So if the database ever leaks, that verifier data can't be used to authenticate to the server. But basically it's a password hash equivalent but not a password equivalent. So why should you use PAKE? Well, it may seem overly complex or scary or something but there are some use cases where it helps with security. So one of these cases is recently, over a span of about a year, these tech companies accidentally were logging passwords. And if the password is never sent to the server, then you can't log the password. You might think, oh, I could hash the password first and send it over but so you secure the database really well but you still log like a simple hash of the password and that's in the log. Those can be cracked easily. But even if you logged all the PAKE data that's going back and forth, you would gain nothing from that as an attacker. Since this isn't like implemented in the browser, it would have to be, you'd have to implement it in JavaScript and sometimes people have JavaScript disabled so you'd have to still have a fallback but that's, you know, like one percent of. So some other uses as I was saying, peer-to-peer. What you can do is secure peer-to-peer file transfer with magic wormhole. You can also, so that's the GitHub page for it. You can also, it's in package managers for Linux. I actually don't know which ones but. So anyway, so, you know, basically what it does is you have this small shared secret that you send, that you tell someone, they type it in and then you can get a secure connection between the two of you assuming that someone didn't man the middle and guess what it was with one try. Another good thing PAKES are for, are for encrypted cloud services like password managers and encrypted backups because they have to do authentication and encryption with your password and there's a lot of things that you can do incorrectly with passwords such as, so there's downgrade attacks that PAKES prevent so a bug that LastPass had was you would log in, it would say, error, well, if the server was compromised, the server could reply with error iterations one, you would be like, oh, oops, I had the iterations wrong so then you would do one iteration which would be a really fast hash and then send that and then it would say error iterations, the correct amount of iterations for your account. And all the user would see is that it took twice as long to log in and they'd just be like, there it's like, then there was Keeper, this was on full disclosure and so the bug here was, so the way authentication and encryption worked on this is there was a salt and iteration count for the authentication key and then there was a salt and iteration count for the encryption key and both of those were run through PBKDF2 and then you would get the authentication key or encryption key but if you sent the, if an evil server sent the encryption salt and iteration count for the authentication stage, the client would just send the encryption key. So that would be really bad. I forgot which way I decided on doing this. So the fix, well, so they don't like people not, oh, not praising them so I'm not going to say this one but it was very obvious from the previous slide when I said what they're doing wrong because they're doing exactly the same thing except for the authentication key is now hashed so you can probably figure out what's wrong. But if any, well, I guess I'm sorry, if they were using PAKES for authentication then none of these tags would work. So there's a bunch of PAKES and which one do you use? So you may have heard recently about Dragonfly and the Pony Award for Dragonblood. So basically it was a timing attack on their hashed point algorithm because it was like an iterated loop which would then leak information. This was actually known to be bad a while ago. I don't know why anyone uses Dragonfly. I guess their marketing team's good or something. But no one's actually done a real life test on such as with Dragonblood which is the cool part. Anyways, so there's SRP 6A. So the clients on the left, servers on the right and those are just, the arrows are just PAKES going back and forth. When you see a key that means at that stage the, that side can encrypt or send, well, and send the authentication key, or yeah, the verifier thing. So you only need to authenticate the user such as like logging into an account. Then you wouldn't need to do the last step. There's the, on the server side, the key is actually available after the first packet. But if you send encrypted data or send the authentication token from the server to the client, the client actually has all the information necessary to do offline brute force. So if you were to do that, your implementation would be really, really bad. So when I was doing the slides, I remembered seeing something weird on Wikipedia like a year ago and being like, wait a minute, this is wrong. So I haven't actually had time to fix this, but according to this, you can skip M1 which is the authentication verification from the client to the server and M2 is verification from the server to the client. If you skip M1 or, well, if you skip M1 and M2 and then you encrypt data to the client before verifying the encrypted data from the client, then the client has everything it needs to do offline password cracking. So opaque, that's the new hotness. So this opaque was presented at real-world crypto a few years ago. So what they introduced was blind salt. So what they introduced was it has this interesting property. So with other pakes, the salt is given to the client or, you know, assumed or whatever. And, you know, like when I say assumed, I mean like the user name combined with the domain name, that's the salt. So what happens with these other pakes is you can run the password KDF which is expensive on a bunch of password guesses. And then, so you store all those keys and then when you want to, what you do is, well, once you're done with enough, you go and break into the server, grab the verification data, and run through all those passwords extremely fast. So if you are in a limited time scale from when you get in to when they're going to change passwords or something, you would want to do this. That's like a theoretical attack. But with opaque, with the blind salt, there's, basically it prevents that by, well actually. So you don't really have to read this, it's just sort of there. So this is how blind salt works. Basically, after it runs through, if you had the wrong password at the beginning, so H, that's a fast hash, that's not like a password KDF or anything. There's no information linkage on this. There's no way to, you know, from the client's message to know, oh hey, the password could have been like better or something. But, so if the password is wrong at the beginning, then when you get back your blind salt, it'll be the wrong salt. And then when you're doing the password KDF, it'll be also wrong. So basically you have to do this all fine. There's one small thing with, so the S column, okay, you can't really see that. So, so server, the part where that's doing its work, if you're doing that with elliptic curves, basically what's happening is the server is receiving a point and then applying a private value to that, the same private value every single time. And what you can do with that is, if there's a implementation error, such as this one implementation had a rare carry bug, and Sean and Filippo, they did a black hat talk about breaking that. They were able to, so every now and then, given a point, it would cause an error and when the value was incorrect, they could then determine some information about the private key. They were able to recover the entire private key. If the secret, the server's salt is ever leaked in a case like that, then it would completely break opaque because that would give you all the data as an attacker to do blind password cracking. So, S-Pake 2 plus EE with blind salt, that's a mouthful. So, basically what I did was, I added blind salt to S-Pake 2 plus EE, and I ended up making the name smaller to BS-Pake, or BS-Pake. Basically, it's similar to the round shape of the S-Pake roundtrips. Well, it is the same as the roundtrips for S-R-P, except for this has an extra property that not many Pakes have. Well, it also has the property that opaque has where it prevents pre-computations. So, this also has a property that is fairly interesting. So, it's sort of quantum resistant, I call it quantum annoying. It's not really a quantum easy problem, it's not really a quantum hard problem. Basically, most Pakes, you have to solve one DLP and then you're, then you can do offline classical computer password guessing. So, basically, with BS-Pake, you have to solve one DLP for every password guess. So, it's fairly expensive, because even if we did have quantum computers, I forgot to look this up, there's this paper that tells you, like, how many quantum operations you have to do to solve a DLP for a 256 bit elliptic curve, which is on the order of a few billion. So, even if you could do, if your theoretical quantum computer could do a billion quantum operations per second, you're looking at, you know, 0.1 passwords per second with a very expensive computer. There is a PQ Pake, I haven't actually looked into it that much, but basically with post-quantum algorithms, we don't really trust them that well yet, so we usually run them in parallel with classical cryptography, like elliptic curves and whatnot. And so, with a Pake, you can't really run a PQ Pake next to a BS-Pake, because you wouldn't get the combination, which ever is the weakest one. So, basically, I think the best Pake to use is BS-Pake. So, this brings us to password KDFs. So, there's many different ones. One that you probably have heard of, or most common, probably, is just computationally hard. It's called PBKDF2. There's just one small problem with it. It has a foot gun. So, it runs in iterations times output length. So, if you ask for, so if you're doing PBKDF2, HMAX SHA-256, each block of output of SHA-256 is 256 bits. So, if you ask for 256 bits of key, then you only do iterations amount of work, but if you ask for 257 bit then it has to do two blocks, and thus it needs to do twice as much work. So, one password, they generated an IV and a key from PBKDF2, and an attacker only needed to generate one of those blocks and decrypt some stuff, and it was Adam from Hashcat that found that. And then, technically Google Sync isn't on this list, but I like bringing them up because they did fairly bad. Basically, for Google Sync, they use Nigori, which the first thing that they do is they use PBKDF2 on constant data to generate assault, then they do three more runs of PBKDF2 to generate three different keys. Technically, they could have done PBKDF2 with just like a long out, which is kind of like what the foot gun would have done. But, and then, first off, the they were using was SHA-1 base, so 160 bits, and they were asking for, or they were storing 256 bits, so their servers had to do twice as much calculations as an attacker would have to. But, good thing, each block of output is independently generated, so is the foot gun to actually make PBKDF2 better, because what they're doing, each block is independently generated, so you can use SIMD, which is Singulant Instruction Multiple Data, like, so with x86, you have SC2, AVX, AVX2, AVX512, AVX512, that can run 16 iterations of PBKDF2 SHA-256 at the same time, so it would be 16 times more work being done in the same amount of time, and then you have multiple cores, so you can make PBKDF a little bit better, but still, other algorithms are better. Um, you really shouldn't be using S-crypt at this point, because of the time memory trade off. Uh, basically, uh, an attacker is the only one that actually uses this, um, to their advantage, because they use less memory, and they do a little bit more work. And, uh, it ends up being faster overall than, uh, so instead, you should be using Argon2, but the problem with Argon2 is, um, for short runs, for like, authentication, uh, you can't use enough memory, it's just too slow. Uh, so, um, technically, a better algorithm would be, uh, a Cashard algorithm. Um, B-crypt isn't actually a, uh, KDF, but there are, like, some weird ones, like PBKDF, B-crypt or whatever. Um, and then there's also Pufferfish, there are issues, but whatever. Um, really, uh, I would say, currently, Argon2 would probably be the ideal way to go. Uh, so, with, uh, so the problem with PIC APIs is, uh, so this is what you usually see when you see an implementation of, uh, SRP. So, Calculate B, Calculate M2, what's V? And, you know, so basically the developer has to figure out what all these are, and then they're like, K, um, and some implementations, uh, leave it up to the developer to figure out whether, they're, how they're supposed to check M1, M2, which one they send first, and whatnot. And, as I said, before with SRP, um, this can lead to, uh, very bad bugs. So, a good API would be one that is easy to use and hard to misuse. So, uh, basically, you start, you say who you are, who the other person is, and your secret. If you're a client, or, you know, it's a symmetric PIC, uh, this would be a password. If you're the server, then this would be your server secret data. Then you say, uh, you let the API know what type of user you are, and what type of mode you're using. And it will return a message, uh, status. You check the status for whatever. And, uh, the message, uh, you may or may not get a message back. If you do, you send it to the other, uh, other side, uh, then, uh, so when you receive a message, you pass it into receive message. And then you get another message, and a status, and as every time you get a message, you send it to the other side, and you check to see if you're finished by the status. And then, uh, there's certain other things that you can do, like get, get server secret, get uh, user key. So, user key is, um, a little bit different. Uh, it's kinda unrelated to PAKES, but so you're supposed to only run the PB, uh, the password KDF once, and derive two keys from it. An authentication key, and an encryption key. And since, uh, we're using, uh, blind salt, and we can't generate two keys beforehand and give it to the API, uh, we have the API run the password KDF. Uh, if you need a user key, which is user specific based on the password to encrypt data that only the user can read. So, you know, like a password vault or a, uh, you know, encrypted backup or something. So, you know, uh, client server, uh, so those are for augmented and then, uh, Alice, Bob. Uh, so there are some PAKES where you have to say I'm Alice, they're Bob, and vice versa. Or, uh, you can say I'm either Alice or Bob and the PAKES figures it up. Then mode, uses you, uh, you know, you're using the PAKES and then, uh, register, that just generates the server, uh, gets, uh, sent to the server. Then the other two are special, uh, for a special case that we'll talk about later. Uh, you know, so these are just the flags, session key available, that means you can encrypt, so that's there. Then you can get the session key and then start encrypting data to the other side. Server secret available, fairly self explanatory, uh, verified other, you know, you've, you, um, have already authenticated the other party. So, in the event that like, uh, uh, you only want to verify the user, you could stop right then, because if you're the server, because, uh, you, that's the whole entire goal, is just verify that the user's password is correct. So, fairly straightforward. Uh, so this is just, uh, so Carol, client, Steve, server, hey, that's me. Uh, those are actually, uh, the common names that are used for, uh, describing client and user, uh, just like, you know, Alice Bob, you know. Uh, so, fairly easy. Um, so, uh, the server doesn't have a server secret yet, because it's on register, so null. And, you know, for using, fairly straightforward. The common, this is for using or, um, it's all pseudo code, but, uh, for using or, um, registering, because all you're doing is waiting until it's finished or errored out, and then you're just passing messages back and forth. Uh, yeah. So, uh, pick, um, wait, okay. Uh, so, uh, basically what you can do as a server is, you can have an HSM that store, uh, that has, uh, that you give it encrypted data, and what it does is it does the whole pick algorithm, um, on it, on its own, so that, uh, if your database ever gets leaked, then the, uh, uh, an attacker wouldn't have the decryption key necessary to, uh, decrypt the verifying data, and they wouldn't be able to, uh, uh, crack any passwords. So, the way it would work is, uh, so the, it is on the far left, uh, out of the picture, one of those go that way, that's basically, so, finds the user, gets the encrypted data, sends it to the, uh, the HSM, decrypts it, and then it has the server secret data, which then it runs the pick, and gets the session key, then, uh, this, this is actually a slide from another talk that I gave, uh, a few years ago, um, at B-Sides. So, uh, this was for um, when you have like an encrypted service, so you would have an encrypted master key, so that when you change your password, um, you didn't have to re-encrypt everything. So, uh, what some does is, it encrypts the, uh, master key with the session key, sends that over to the client, no one in between the, uh, the HSM and the client can read these packets because of the pick session, and then a little bonus feature is you can drive a second key from the session key, or another session key from the, uh, session key, and give that to the server so that they can, uh, talk to the client in a way such that no one in between the server and the client can man in the middle of that without, uh, knowing the password. Uh, so, secret salt. So, this is used by, um, well, they call it something else, they change the name a few times. Uh, this is used by one password. So, what this allows you to do is, it's basically a key that's on your device, and you never send it to the server or anything like that. Uh, and you basically transfer it to all your devices, um, some way. And then, uh, what it does is, it makes it so that, um, an attacker would have to get your device, get the secret salt, and then they can then do online password guessing, uh, to the server. Um, which means that if it was in, like, a password manager, uh, it would be actually more secure than a offline password manager. Um, sorry. All right. So, uh, there is one small thing about one password. Um, so, they require you to use a, uh, their password. So, they require you to web client, which means if their servers are ever, um, attacked or, you know, uh, infiltrated, then when you do use the web client, uh, then they can extract, uh, send malicious JavaScript, which then can extract your key, which would be bad. Um, but, uh, that's only, uh, during administration, because, uh, that's not actually implemented in any of the, uh, uh, apps that they have. Uh, so, uh, recovering a lost secret salt. Um, I wrote a blog post about it. Uh, you can actually just go to top2.com slash blog. Uh, you don't need to be stressed. Uh, I was lazy and it's just like, uh, uh, you can, uh, it's just directories. So, um, so to the basic idea behind recovering a secret salt, um, so if you ever lose the secret salt, then, uh, you're screwed. Uh, even though you know your password, you just can't, uh, log in. And, uh, this would be really bad for users, which is why you need to make paper copies, which they won't make, and what, but, so, technically, taking a recovery option for, uh, secret salt would invalidate the entire idea of having a secret salt, except, um, there's this little trick. Uh, so, when you're doing, uh, so the recovery method is you do the password KDF with the, with another blind salt and your password and this guessing salt. It's like 16 bits. And what you do is after you run the password KDF, you throw away those 16 bits. And what you have to do from then is you have to, when you're recovering, you have to brute force those 16 bits that you don't know. So, if you ran a password KDF that was argon 2 with like 256 meg, 1, uh, 1 thread, 3 iterations, uh, it would run for about 1 second on your computer. So, it'd be like 18 hours. You'd probably have a few less bits than that. So, that it would run in a, uh, more reasonable amount of time, like a couple hours. Uh, the thing is, uh, you never actually, you're rarely ever doing this. So, um, from the user's standpoint, uh, it's, I never get my account back or I have to do 2 hours of hard computations on my computer. And since, uh, I've been doing this for a long time, it takes, um, you know, 2 hours for 1 password guess. If a password cracker got this, that is a ridiculously slow speed. Um, so, the, uh, well the, uh, so the recovery method also uses a opaque and whatnot. But, um, uh, that's what those 2 extra ones were, the blind salt. So, you would, uh, actually, do do, uh, there we go. So, uh, these 2, uh, blind, uh, only blind salt, you would do that with your password, and then you would get back your blind salt. Then, you would go, uh, do your, uh, basically brute force the guessing salt. And then, after that, you, uh, you would have a bunch of candidates, which you would then use, uh, use after blind salt. Uh, you're also given a, a very short, a smaller hash than the guessing salt. So, you'll have a, a few, uh, like 10 or whatever, um, that you would have to do, uh, uh, opaque operations with the server. So, then, then you would have a session key, and then you would decrypt the, uh, the secret salt that you lost. And then you would have it back. Uh, questions? Yeah. All right. Thank you very much. Any questions? I'm slowly making my way up to the front. Can we, can we, can we have this with the mic please? I'll be right there. Thanks. Sorry, I walked in late. So, I missed what a blind salt is. A what? I missed what a blind salt is. Oh! I walked in. Sorry. There we are. So, uh, basically blind salt, uh, prevents pre-computational attacks. Um, it was, uh, first added into a, a opaque with opaque. Um, so, basically with this, uh, um, so, basically, uh, after you run through this, uh, if you had the wrong password, you have the wrong salt for when you run your password KDF. And there's no information linkage, uh, in the algorithm. So, you can't, you can't uh, like guess or what not. What the password was from the server side. And, uh, this makes it so that you have to do online password guessing. Hi. Uh, well thanks for doing this talk Steve. I, I think pakes are definitely underutilized and the landscape is definitely kind of confusing. So, uh, have you thought about contributing an implementation of your API to something like lib sodium? Just to make it easier for developers? Um, so, uh, the nice thing is, you can actually, you don't really have to write much. Uh, you just have to write the, uh, basically like a wrapper for, uh, current implementation. Uh, what, uh, project did you say? Uh, lib sodium? Or, uh, any other general crypto library? Uh, yeah, um, I did, uh, uh, talk to, uh, I forgot his name. Uh, lib sodium, uh, guy. Uh, Fredrick, yeah, Fredrick's. Um, uh, he, he didn't like it, so. What? No, he, he didn't like it. But, you know. Uh, thanks for your talk. Uh, could you repeat again, um, how opaque and BSPAKE compared, like, are they, um, different? So, um, opaque, uh, basically, so with opaque, it's fragile for implementations because of the, uh, blind salt. Uh, basically, if you solve that DLP or figure out, you know, like what the salt is through some, uh, coding error, uh, like, uh, the carry propagation, then the, an attacker would be able to get, um, offline, uh, password guessing. And with, uh, uh, BSPAKE, uh, it does add, uh, some, uh, another, uh, pass back and forth. Er, well, one more trip. But, um, it has an extra property that is, uh, quantum annoying. Uh, it's just a name I came up with, I'm not really attached to it. But, um, basically, uh, due to the hash to point blinding on, uh, the, well, the, uh, the base function, uh, the, uh, the, uh, base function, uh, uh, SPAKE 2 plus EE that it's based off of. Uh, that blinding, uh, prevents you, well, it requires you to, uh, solve one DLP for every password guess. So, um, so with hash to point, um, what that does is it creates a point on the curve that you don't know what the, um, the, uh, the, uh, discrete log is. So, uh, when you are trying to attack this, you would have to guess a password, then hash it, it would go hash to point, then you would subtract it from the message that you saw that went by, and then you would have to solve the, uh, the DLP for what's left. And you would have to do that every single time. First, other PICs where you just have to solve one, and then you have everything that you need. Oh, there was one other thing with OPEC, uh, you don't need to observe a successful key exchange, but with, uh, uh, base fake, um, you have to observe a successful key exchange to be able to then, uh, use a quantum computer if it were to exist. Uh, and then you would have to do one for every guess. Any further questions? Alright, one last round of applause for our speaker. Thank you.