 So thank you for the introduction and good afternoon So I'm going to present some work that we did on the dragonfly handshake on this was done in collaboration with E.L. Hohnen So the dragonfly handshake has recently been Used in WPA3, which was announced about a year ago On the dragonfly handshake before that was actually already in use by the EAP PWD protocol now what is the EAP PWD protocol? Well, it's another protocol in Wi-Fi which is used by a small amount of Enterprise Wi-Fi networks where you authenticate using username on password For example about two to five percent of iterum networks use EAP PWD on that also uses dragonfly So let's first briefly introduce what the dragonfly handshake actually is so the dragonfly handshake is a PAKE it's a password authenticated key exchange Which in practice means that? Authentication happens based on a shared password on Besides that the dragonfly handshake also negotiates a fresh session key which after the handshake can be used to Encrypt actual data traffic Now the interesting property that dragonfly and a lot of other pakes provide is that it offers Forward secrecy and it protects against dictionary attacks And that's a huge advantage compared to WPA2 for example because with WPA2 an adversary can just passively capture a handshake You can he or she can take that handshake offline on do Dictionary or brute force attacks against it Now a few other pakes also have another property namely that they protect against what I called here server compromise in other words, they're also augmentant on asymmetric pakes where if for example the server is compromised It's difficult for an attacker to then try to recover the original password So you can think of this that the server can store a salted version of the password in a sense Unfortunately dragonfly does not provide that property So a dragonfly if you manage to compromise for example access point or the router you have enough information to print Pretend to be a client So let me give a high-level overview of how dragonfly works So let's say we have a client that wants to connect to an access point Then the first thing that needs to happen is that the password which is for example stored in us key It needs to be converted to a so-called group element, which I will represent using P On this P can be used in the actual cryptographic calculations Once this is done The handshake essentially consists of two main phases. The first is the commit phase Where we negotiate the shared secret and then we have a confirmed phrase where both parties essentially Confirm that they negotiated the same key on that they both are using the same password Now what's the interesting? part here The interesting part is how the password is converted to a group element P because this is where a lot of Vulnerabilities on a lot of side channels occur Before I get into that there's one important remark And that is that the dragonfly handshake can be executed using both so-called mod P crypto groups aren't using elliptic curse So let me first zoom in into the mod P groups first very quick background what our mod P groups basically means your Calculations are done modulo P Hensh the name as well But what's more interesting here is how is the password converted into a member of the script a group? And a naive first attempt would be the following algorithm Basically, you take the password here using represented using PW You hash it together with the MAC addresses of the client on the access point Onto you interpret it the resulting value as an integer Then you just calculate some form formula here, which converts it into a member of the mod P group and This would be this would work. Well, except there is one small problem And that is for certain mod P groups the prime of the group Well, actually the value the resulting value here might be bigger than the prime of the group that is being used now One simple solution would have been to simply take the hash here and then do modulo P So mod P to get a number smaller than P, but that introduces a small theoretic bias into this value So how did they decide to tackle this instead? Well, they decided to add an if test here on if the value is bigger than P then we actually include a counter here on If this value is smaller than P the first time we simply increase the counter try again Until we finally have a value that is smaller than P so most of you can probably already see the problem here and Namely the number of iterations that are needed here depends on the password On in fact, this was already pointed out by the IETF on CFRG when this algorithm was being proposed so already Back in 2010 When there was the first standardization efforts of Dragonfly in a mailing list it was mentioned that you know This design is susceptible to timing side channels and it may leak the password on What they recommended to do is to exclude the MAC addresses from this algorithm Because then you only need to execute this algorithm once and not every time that the handshake is executed Now what was the reply at least at the time well the reply at the time was Well, I'm not really sure how important this is They thought it wouldn't leak the shared password on that the resulting attacks are quite complicated Now their opinion changed a bit over the years, but initially that was the reaction So let me come back to this first remark here that it's uncertain whether this really leaks the shared password or not So what can we as an attacker do well? Let's say that an access point is using WP a3 with this algorithm that we just saw As an adversary I can then try to connect as a client for example using the client uses MAC address a On using a timing attack. I can measure how many iterations that the access point needs Let's say that I measure. Okay, the access point needs two iterations to convert the password into a mott P element And I then have a dictionary of possible passwords Here I just have three as an example on what I can then do as an adversary is run this algorithm on my own laptop And see how many iterations are needed for a specific password on see if it matches my observation So here in this example password one uses a different amount of iterations. So I know that password is not in use But there's still a lot of other possible passwords that remain So how can I gain more information as an adversary? Well Remember that this algorithm here depends on the MAC address of both the client on the access point So I can just spoof a different client MAC address I can again measure how many iterations are needed and I can just repeat this process So here in my example password to would use a different amount of iterations If I spoof client address B so I can again include exclude This password and I can keep doing this for another Mac address Also on until I uniquely identified the password in my dictionary To give you an idea how many Mac addresses you need to spoof for this Let's say you use the rock you data password dump Then you need to spoof around 17 Mac addresses to be able to uniquely Recover the password. So that's not too much and The main takeaway lesson here is that the amount of iterations that are needed To convert the password into this mod p element If you measured it this for several Mac addresses Then you essentially have a signature of the password which you can use in offline brute force attacks But there's one thing I Haven't discussed here yet on that is is making these timing measurements Feasible in practice. Can I really determine how many iterations that the Mac that for example the access point is executing? So we tried this in practice What we did is we took a raspberry pi one The reason why we took a raspberry pi one is because its CPU is similar to home routers aren't even similar to some professional access points on On this raspberry pi we ran host APD as the access point which is the most widely used Software for Wi-Fi access points is used in home routers using even quite some professional access points So that is the setup we used and We noticed that Measuring the number of iterations is quite feasible under this setup To give you a concrete number if we make around 75 timing measurements per Mac address We're able to determine how many iterations that the access points needed So that's quite feasible in practice now Recall that in the beginning of the talk I said that we can use multiple groups But that the handshake can also be used using elliptic curves Now I guess for this audience. I don't really need to introduce elliptic curves Basically, all operations happen on a point X and Y X and Y have to satisfy a certain formula The real question here is how can we convert the password to a point on the elliptic curve? So that we can then use this point on the elliptic curve for our cryptographic operations well Initially, they proposed a very similar algorithm to the one-format P groups Namely we again have a loop here with a counter We calculate a hash based on the counter on the Mac addresses The result is interpreted as the sorry as the X coordinate and then we simply see if there is a solution for the Y Coordinate and in about half of the times there is indeed a solution for why and we have found a point on the elliptic curve Now here you can see that we again have exactly the same problem the amount of iterations depends on the password being used Unfortunately for the EPWD protocol, which remember it's using certain enterprise Wi-Fi networks There are no defenses against this timing leak at all What's Interesting is that for WPA 3 they did realize there would be a timing leak here so for WPA 3 they decided to Simply execute this loop always 40 times. Let's just ignore the computational overhead that this causes They decided to implement this defense here and what's a bit surprising here is that in the case of elliptic curves They have this defense against timing leaks where they just always do 40 iterations Independent of when the password element was found While for the mod P case They don't they didn't have this defense. So that's that's quite surprising Okay, so we have this defense and There's one more thing I need to mention here on my opinion It's a bit of a leftover of Discussions that they had about this algorithm and this is that for the extra iterations that are being performed to reach 40 iterations They do these iterations based on a random password So once we have an X on that we have a solution for Y We now do extra iterations based on a random password On you can just consider that to be a defense in depth so far This algorithm would actually be fine on if we use NIST curves. There would be no timing leaks But there's one problem and that is that WPA 3 also explicitly supports brainpool curves What's the problem with brainpool curves there again? We have the case that the results here of our hash hash function the X value It has a high probability of being bigger than the prime being used by our elliptic curves On you can maybe see where this is going They decided to handle this the same way as with mod P groups if X is bigger than the prime We just increased the counter on try again Now here we still do these 40 iterations even in this case But still there's a problem here because if X is smaller than P then this code here is skipped And in particular the amount of times that this code is skipped again depends on the password There's one catch that makes this a bit more a bit harder to exploit in practice because the amount of times that this code is skipped also depends on our Random password that is used in the extra iterations So that adds a bit of complexity but This still leaks information Because the variance of the execution time depends on when the password element was found For example, if the password element was found here in the last iteration Then there are no extra iterations based on a random password. So there's basically zero variance If the password element is immediately found there are a lot of iterations based on a random password Meaning there's a lot of variance On top of that the average also still leaks information as well because that just average averages out this random noise So now the question here again is is it is Are these timing differences measurable in practice on? Without going into too much detail. Yes, this is the case But these timing measurements are a bit smaller than with a mod P Example that we had on here We need about 300 measurements per MAC address to gain useful information as an attacker On the resulting timing measurements, they can again be abused in a similar way They form a signature of the password and we can use this signature in offline dictionary or brute force attacks so This covers the timing attacks now apart from that. We also looked at other side channels namely cash attack side channels so Another way to attack this algorithm on to know When the password element is find it is found is to I'm simplifying a bit here, but basically we can use flush and reload to detect when a solution For why has been found? Now there's one thing that makes these that makes this a bit more tricky is that We also need to know in which iteration this was found So we don't just want to know is this code executed. We want to know in which iteration was this executed on And our specific example that we tried we wanted to know is this executed and do we have a solution here in the first iteration or not? On to able to be able to determine this We also used a cash attack basically to monitor when this hash function here is being called So in a sense we monitor when this hash function is being called sort of as a clock to determine in which iteration We are And we can do the similar thing for brainpool curse We can also try to find out when here the x value is bigger or smaller than p by Monitoring when this function here is being executed that checks if there is a solution for y So for brainpool curse, we roughly have a similar cash attack on these cash attacks are fairly Reliable in practice the ones that we use Now these attacks do require a more powerful adversary than the timing attacks. We need to be able to run unprivileged codes on Either the machine or the victim That's still quite feasible. We can for example imagine a malicious Android executable or Some previous works have shown that at least an older browsers. This may be possible even from JavaScript So against the client. I think this is a realistic scenario In theory, this would also be possible against the access point, but against an access point it may be more difficult to Run malicious codes on that Maybe the one exception here is is is if you set up a hotspot on your phone, then it Would still be feasible Now The information that is leaked here in our cash attacks We can use this well it again forms a signature of the password basically Just like the example we had previously on the signature can be used to partition Dictionary on to then uniquely recover the password once again So that's actually quite interesting because for both the timing attack on the cash attack The result is a signature of the password and this signature is used in a brute force algorithm On in fact is used and almost exactly the same brute force algorithm So it makes a lot of sense to optimize the brute force the dictionary attack algorithm and see how efficient Though these attacks really are in practice So what we did is we implemented the brute force on the dictionary attacks on GPU code and we found that if we want to brute force 10 to the power 10 Passwords or a dictionary of that side size We need less than a dollar in Amazon easy to instances Now to give you some Intuitive idea about this number here. This is bigger than all possible Dictionaries or password dumps that you can find it's bigger than the rock you dump It's bigger than all the passwords on have I been pwned. It's bigger than an English dictionary So if you have a dictionary you can brute force it using a dollar At least if your timing attack or cash attack Succeeded so that's quite a low amount of money. So we thought okay How about instead of just dictionary attacks? We also look at the complexity of full brute force attacks So let's try to brute force all Passwords of eight characters over all possible symbols Well, it turns out that if we then want to attack mod p or brain pool groups This costs about 70 dollars, which is quite cheap in my opinion if we want to attack NIST curse then the brute force Calculations is a bit more expensive because we have to check whether there's a solution for why which is a bit more costly than checking The case for the mod p on brain pool curse and practice this means that the cost is higher if this curve is being used So that would cost about 14,000 dollar It's a lot more but considering that you know, this is a this is a Encryption protocol that is very recently been proposed This is quite a low amount for a modern protocol to be broken that easily And if you want to know more Details about how we estimate it is or if you want to know the results for other sizes I referred it to the paper where we analyze this in a bit more detail okay, so Let's recap a bit so far. We've had side channel attacks We've had timing attacks where they were actually warned about these timing attacks yet They didn't defend against them properly. We have new timing attacks against the brain pool case. We have cash attacks On on top of that. We're now also going to discuss some implementation specific vulnerabilities as well on The first one that I want to discuss is an invalid curve attack so Let's say we have the following situation We have an access point here that we want to attack and We as an adversary are going to send a commit frame and This commit frame contains a point on the elliptic curve But as an attacker we can decide to send actually a coordinate. That's not on the curve Normally the access point is supposed to detect this But if it doesn't we can carefully pick the X and Y values to make sure that the Secret key that is being negotiated is very predictable So if the access point doesn't check whether X and Y is on the is on the curve The negotiated key is predictable. The access point won't realize this and it will just continue executing the handshake Now in our specific case we can actually guess the negotiated key here with roughly 66% chance of having it right So we can guess the scheme and then just try to complete the handshake and if our guess was correct We successfully authenticated with the network on we're essentially impersonating a client So which implementations were vulnerable to this well, we have all EEP PWT implementations that were vulnerable. So this is free radius. This is host APD. This is Commercial clients every single one that we tested was vulnerable with WPA 3 We were able to test some early implementations on open source ones on there the situation at least initially seems a lot better because they're only IWD is vulnerable And IWD is in relatively recent open source Wi-Fi clients for Linux So I'm not going to go into detail here how this invalid curve attack Works in detail how the X and Y is picked. There's a talk after this which the Bluetooth one Which I think goes into more detail about invalid curse attacks as well So I'm just going to keep it at this high level Another attack I instead want to discuss is a reflection attack and in this case I'm not going to assume. We're attacking WPA 3 in the example diagram here. I assume that we're going to attack EEP PWD Now why am I taking EEP PWD as a specific example here? Well, that's because with EEP PWD The dragonfly handshake is initiated by the access point While with WPA 3 the dragonfly handshake is initiated by the client And in this case we can do something interesting namely we can first go through the Wi-Fi Association stage the access point will then send the commit frame and we as an attacker can just Reflect exactly the same frame back to the access point with some minor changes If the access point doesn't realize that this is a reflected flame frame It will simply continue the handshake. We can also then reflect the confirm phrase And we can then successfully complete the handshake without knowing anything simply by reflecting these messages on This is in a sense a very basic attack Because we can fool the access point into thinking that a certain user authenticated with the network Now we won't be able to reveal the session key that is being negotiated here So we cannot send client so we cannot send traffic as the victim here But in certain cases this might still be useful For example, you can imagine a case where if a user successfully connects to the to the network Then maybe you run some script or unlocked some device. So Admittedly, this is a bit of an edge case, but in certain cases this might still be a risk Normally implementations are supposed to Detect this they are supposed to check whether this x and y is the same one as that the access point just sent now Here we have a bit of a similar story as before all EEP PWD implementations are vulnerable While with WPA3 the situation is a bit better with WPA3 only old WP supplicants are affected But this is a bit of a common theme that we noticed namely EEP PWD The security of its implementations is a bit shaky in practice so We actually have even more we checked for more implementation vulnerabilities as well on Another interesting one that I want to highlight here is that we noticed one client It's an EEP PWD client that used bad randomness In particular it generated random numbers based on the system time on some other Inputs, but basically we could predict the random numbers that it was going to use What's interesting about dragonfly is that If we can predict the random numbers that a certain client or peer is using We can recover the password element P And then we can impersonate either the client or the access point So if bad randomness is used the impact is catastrophic And we noticed this in one case but My hunch is that in practice this might also occur on other devices For example, if you have a cheap iot Wi-Fi device It may not have the best source of randomness So I think this might be a risk in practice on What's interesting here as well is that the impact of bad randomness is actually worse with WPA 3 than with WPA 2 Because with WPA 2 if you have bad randomness there At worst what you can do is a key reinstallation attack or you might When you want to do a dictionary attack You can already do some pre-competitions before you carry out to attack But in general the impact of bad randomness is worse with WPA 3 one final implementation flaw that I want to discuss is It's actually a side channel, but a bit of an implementation specific side channel There's a bit of an interesting history Recall that in the beginning of the presentation We had this algorithm that converted the password into a group element of the crypto group Initially EPWD didn't have a timing leak defense against this But after a while Implementers did realize that this was a problem and they decided to try to implement some countermeasure measure against this And what free radius decided to do was okay Let's always do at least No, actually, I think they had no defense against this. They just tried to Find the password element and once it was found it returns But there was another problem here that if it needed more than 10 iterations Then the handshake would just abort Now that's problematic because in one out of 2048 handshakes you do need more than 10 iterations So what can I as an attacker do I can just initiate about 2,000 handshakes and On average one of them will fail and if the handshake then fails I know that okay, that means free radius needed more than 10 iterations And that gives me a lot of information about the password on that leaked information I can again use to do a dictionary or a brute force attack So here against free radius you didn't even need a timing attack or a cash attack Simply perform about 2,000 handshakes one of them on average will fail That leaks information Once you can then recover the password Okay, so you might think now that we covered most attacks mean we had side channels implementation flaws But we're not quite done One other thing I want to mention is some risks that are really specific to Wi-Fi at least in my opinion The first one is that The access point here always needs to convert the password to a group element P when a client is connecting It cannot do this computation beforehand Because remember that the P here depends also on the MAC address of the clients on you don't notice an advance So every time the access point Notices that a client is connected it needs to run this algorithm The problem is this algorithm now if you implement all the fences Needs to execute. Sorry 40 iterations all that every single time on that's a ton of overhead on if you use an elliptic curve of Around 500 bit size then we found this was against a professional Access point that just recently supported WPA 3 if you make if you forge eight connection attempts per second Then the access point is actually already fully overloaded and it won't accept any other WPA 3 handshakes, so that's a very low amount if you use a smaller elliptic curve of 256 bit this is a around 70 connection attempts on then the access point overloads, but it's still not ideal this is in fact one of the big issues with dragonfly is that You can either decide not to perform these iterations on be vulnerable to timing leaks Or you can implement these iterations on then risk denial of service attacks So now as an implementer You're always sacrificing something which indicates that there's really some design flaws with the handshake here another Wi-Fi specific attack. I want to mention is that If you want to deploy WPA 3 not all devices are immediately going to support it So you want backwards compatibility. It's a usual story The way that the Wi-Fi lines suggested to handle the backwards compatibility problem is to if you set up an access point to Configure WPA 2 and 3 using the same network name aren't using the same password Unfortunately, this is not a perfect defense Because Well on one hand it does prevent some attacks because let's say I have a client that supports WPA 3 aren't an access point that supports both WPA 2 and 3 If I would then try to act as a man in the middle and try to force the client into using WPA 2 So if I if I would try to downgrade it The client would actually detect this attack because a WPA 2 handshake does detect downgrades Which in this case means that this setup does provide forward secrecy But there is one rather big problem and this is that a partial WPA 2 handshake is still executed on this partial WPA 2 handshake is still sufficient to Then perform a dictionary attack Another works another word words the way that the Wi-Fi lines Suggests to simultaneously use WPA 2 and 3 at the same time is vulnerable to downgrades meaning you gain little advantage of Configuring your network in this way So maybe you're now wondering, okay, can we defend against this at all? I mean disabling WPA 2 isn't really an option as at this time Fortunately, there is one thing we can do That is as a client as a client device We can remember whether an access point supported WPA 3 in the past And if so, if it previously supported WPA 3 we do not fall back to WPA 2 automatically Unless maybe the user explicitly enters the password again or some other indication And this is similar to the trust on first usage of SSH and Also with certificate pinning on HTTPS On the good news is that for example the Google Pixel 3 on the Linux network manager They have actually implemented this defense. So if you use those devices, you're not vulnerable to downgrade attacks Unfortunately, this isn't the only downgrade attack that there exists The story goes on Recall at the beginning of the presentation I mentioned that this handshake can be used using modp groups. It can be used using elliptic curves And it can be used using quite a lot of elliptic curves actually which Make makes you wonder. Okay. How does it then negotiate which group to use? Well, it uses a simple mechanism here the initiator Suggests which group it wants to use on the responder simply says yes or no The problem is this reject message of the responder it can very easily be spoofed and After the handshake there is no kind of mechanism to detect if someone tried to manipulate or mess with the handshake So as an attacker all you need to do is For example jam a message which is feasible using cheap Wi-Fi devices So basically downgrade attacks are quite easy and this is really a design flaw in the standard against On all implementations are vulnerable to this The only defense against it is to only use elliptic curves or modp groups that you know that are secure Yeah Okay, so that was downgrade attack number two you think there's gonna be a third one Well, there is but it's not a downgrade attack against the specification or against the standard But we also did notice a downgrade attack against two Very recent implementations of WPA 3 Namely what we noticed there is if you set up a WPA 3 only network And you connect to it using for example Samsung S10 Then this Samsung S10 should remember. Oh, I connected to a WPA 3 only network So this password I should use only with WPA 3 Well, it turns out if I set up a WPA 2 network with exactly the same network name then The Samsung S10 on the IWD client will use that same password to connect to WPA 2 as well Meaning you have exactly the same issues Now this is just an implementation flaw. It's not a flaw in the standard But it's still something interesting to highlight as well Okay, so that was quite something but we finally went through all the attacks that we found The last thing I briefly want to discuss is the disclosure process that we followed And our goal here was to disclose this as early as possible with the hope to influence WPA 3 before it was deployed A bit to our surprise We were met with some skepticism here because initially they considered this to be implementation flaws The standard is fine. We can just patch implementations aren't we good There was even one surprising comment of one developer who said oh, yeah We are we're actually aware of one of the downgrade attacks that was discussed during some standardization meetings We just forgot to warn about it Okay So what was then the official reaction of the Wi-Fi lines? they privately Created security guidelines on how to properly implement WPA 3 and In those guidelines, they said brain pool curves are perfectly fine to use. You don't need extra defenses But as I explained earlier in the presentation even with brain pool curves timing leaks on Timing leaks are possible So we actually had to go through a small second disclosure to fix The mistake they made in their security guidelines Which they privately created so this is again also the same story. Don't create guidelines and private Ask for feedback first Now even with these security guidelines of the Wi-Fi lines, there's still two major problems The first one is that implementing WPA 3 without any Possibility of side channels is extremely hard I would even compare it to the CBC mode attacks of TLS where if we keep using this maybe every year We're gonna find some new attacks against this Another problematic thing which I already highlighted is that To defend against timing leaks they currently suggest using 40 iterations Now this is quite costly especially on low-weight for example IOT devices And you may think now here that oh, but that's okay. I have a powerful smartphone or laptop. I'll be fine. I don't care Unfortunately, even if you have a powerful smartphone or computer The WPA 3 handshake so drag-and-fly might be offloaded to the Wi-Fi chip itself Which is again a light lightweight chip So even if you have a powerful laptop The Wi-Fi handshake itself is handled using a lightweight Wi-Fi chip where these timing attacks might still be feasible Unfortunately this argument was the one that convinced vendors the most I think to update the standard so On one hand, it's good that the standard is being updated on the other hand I have the impression that it's mostly done because of the overhead issues here The good news is they are updating it So our you are preventing the group downgrade attack. They are now allowing to do a large part of this algorithm That you can execute this when you configure the password when you enter it So not so that you have to do a lot less work for every individual handshake On top of that for the mod p groups They are now prohibiting weak groups and they are moving to a constant time algorithm to convert the password into a group element On the same thing is true for elliptic curves there. They are restricting the use of weak elliptic curves on they are again using well, they are proposing to use a constant time algorithm It still has to be approved So all this might lead to WPA 3.1 It's unclear how this will be handled because these changes. They are not backwards compatible Now I recently Saw some remarks where it was said that this update might be Seamless to the user that the user might may not notice a thing about this update Which to me might indicate that there's a risk of possible downgrade attacks back to the old WPA 3 It's unclear how this will be handled. That's a possible risk Now there's one last message I want to give to the ordinary Wi-Fi users And that's that if WPA 3 comes out I still recommend to use it Because at least for now it still seems better than WPA 2 Yes, we have the side channels where we can then use Dictionary attacks on wood force attacks, but it's still harder to do these attacks with WPA 3 With WPA 2 these attacks are quite easy with WPA 3. It's harder For example making these timing attacks. It's harder to do that compared to just passively capturing a WPA 2 Pancheek So that gets me to the end of the talk to conclude WPA 3 is vulnerable to side channels The countermeasures against this are costly because of that. The standard is now being updated Maybe the most interesting observation is that a lot of at least quite some of these side channel issues could have been avoided Remember in the beginning of the presentation where in 2010 someone recommended to exclude the MAC addresses From the algorithms that I discussed If they would have followed this advice a lot of our side channel attacks just wouldn't have been possible or they would have been a ton more difficult So I guess the advice is don't just ask cryptographers for advice. Listen to them as well So with that, thank you for your attention Thank you. Thank you. Thank you very great talk. Please Regarding the mod P the mod P prime Do you know where they got that from? Because I'm thinking, you know, there are RFCs where the the modulus is like ff ff ff Stuff ff ff f and the chances of it ever iterating are essentially zero Now the mod P curves here have the 160 bit I guess Q so they're different not curves different primes But they could have done the same thing right they could have found a Prime that was almost 2 to the 2048 But still had a mod Q subgroup, but they didn't do that. So, do you know where that curve now where that prime came from? So they could have indeed used mod P groups where they wouldn't really have had this issue or at least have a very small chance that This value is bigger than the prime. I Guess maybe one of the problems with dragonfly is that they really try to support a lot of groups Including one of the mod P groups where this is an issue. So I would say the maybe the problem is that they They wanted to support too many crypto groups than was really necessary And because of that they had one of these groups where it was an issue But that seems to be the one that they're using Well, it's not the default one, but it is one that is officially supported in the standard. Yes, okay Thank you, but you still don't know where they got it from like was it in a nest standard or a It wasn't one of the RFCs or standards yet. It's it's a it's a group that was previously defined Yeah, yeah, it could also be from IP sec I thought the IP sec ones were the ones Hilary Orman designed which which are safe primes, you know But but it's definitely not a new group. It's one that existed before. Okay. Thank you Hey, great talk. I have a question regarding the invalid curve attacks So from my own experience is quite surprising what you found so many of them because usually developers use Libraries for this because they think elliptic curve is too spooky and too complicated. Why is this not the case in vpf3? Can you repeat the beginning of the question? Why are developers of vpf3 not using libraries because it's usually too complicated for them. Well So does this refer to an invalid curve attack? Yeah. Yeah. Yeah, so they are using libraries there So some implementations use open SSL, but They forgot to call the open SSL function that checks whether the point is on the elliptic curve on New open SSL versions do this implicitly. Yes, but all the versions don't on quite some Implementation still use the old version of open SSL where this is not checked. Okay, that explains it. Thanks Sorry, I came in late, so maybe you've already addressed this if I'm moving around with my mobile and addressing multiple Wi-Fi hotspots The it's gonna have to go through it in fact it already is going through a lot of trouble to Constantly check on the second and third best access point Isn't this generating an enormous amount of computation for all the access points even with no data actually being transmitted So is the question how much so if you scan for networks But I'm constantly scanning as I'm moving because I may have to switch within the next second, you know So well that uses some amount of energy as well and computation But I think that's still quite low compared to doing a WP a3 handshake So you don't have to redo the basic handshake all over again. So when you're just So is the question when you are connecting to other networks or only searching? Well, no, you're constantly searching, but you may immediately switch so you don't have time Otherwise you'll drop the if you're on a phone call or something else So in other words, you have to be prepared to switch at any within. I don't know 20 milliseconds or so so So just searching for networks, of course doesn't involve the WP a3 handshake Now, let's say you're walking around your house and you're constantly switching from access point to access point then Depends a bit What version of Wi-Fi you're using there's one extension which allows you to seamlessly on more efficiently switch from one access point to another If you don't have that update depends a bit how WP a3 is implemented There it depends Again, some cases you will have to redo and eat the complete WP a3 handshake every time Against other cases you don't and you can reuse the previously negotiated session key essentially because they're also talking now about putting Wi-Fi and cars And having the cars talk to one another on the on the road Yeah, yeah, so so I think there they're counting on one of the extensions on Wi-Fi where you have like fast transition to handle that in a Hopefully better way so Okay, I think if you have further questions to Marty you can ask him in the next coffee break. So thank him once again and See you in 30 minutes