gipsies

In the future people might think the same about Bitcoin and AI.

There needs to be extra evidence before claiming that "virtually all VPNs apps" are vulnerable. From my understanding, they tested WireGuard on multiple platforms. However, other VPN clients may install extra firewall rules, I've seen that happen with VPNs on Windows/macOS/Linux.

Several of the implementation flaws allow an attacker to essentially inject plaintext frames in a Wi-Fi network. All that's needed is being within range of the network (with an extender you can still be far away). I agree that the design flaws aren't that serious! But that's also explicitly mentioned on the website so...

Edit: injection can be used to punch a hole in the router's NAT so someone can directly try to attack your devices. As always there world isn't burning down. But I think it's interesting research :)

What's actually interesting is that they have some world-top cryptographers and security researchers (e.g. invented AES and SHA-3). So part of that money goes to academia, and with good results :) The government agencies are lagging behind though.

I again feel that most of these points are all discussed in the paper. Trust-on-first-usage is also used in SSH. Attack uses spoof MAC addresses, hard to rate-limit that. Modern crypto should be designed to reduce chance of implementation flaws. Paper concludes that WPA3 is still better than WPA2. Most attacks are on WPA3's Dragonfly. Etc. The most practical attacks are downgrades to WPA2 though, so the press might focus too much on that..

Exactly, since there is no state machine, an attacker can immediately send the last message. The client will try to check the integrity of this message. But it will use an uninitialized all-zero key to do this! So an attacker can spoof the last message. And once the client receives this message, it will accept all traffic.

No, the standard is secure. This is a vulnerability in the implementation. The comment in the code merely says that the explicit definition of the state machine behind a 4-way handshake implementation is not in the standard (but it's described in prose). Most standards don't provide explicit state machines.

The 802.11i is the official standard. WPA1 is based on a draft of 802.11i, while WPA2 is based on the final version of 802.11i. All of them contain the 4-way handshake.

Not really. The STA may know that its message was received, but can never be sure whether the AP replied. The reply from the AP could have been missed due to noise, or maybe it didn't reply at all. You cannot be sure. There are only heuristics.

Good drivers indeed tell you whether the message arrived or not. But it's up to the client to decide what to do with that information. And again, it's just a heuristic. I've read and messed with the code of four different Wi-Fi clients, and none of them attempt to detect a bad password this way. Most simply report an error after trying to retransmit message 2 multiple times (e.g. if wpa_supplicant got message 1 from the AP, but didn't get a reply to message 2, it warns that maybe the password was wrong).

If you're using a pre-shared key, the password is verified during the 4-way handshake. The thing is, if your password is wrong, then the Message Authentication Code (MAC) of the messages your are sending is wrong. The AP will simply drop frames with a wrong MAC, and will not respond to them. The problem is that as a client you do not know whether the AP is not responding because (1) the MAC was wrong, and hence the password was wrong; or (2) the message did not arrive at the AP (or you did not receive the response of the AP).

tl;dr: can't tell the difference between dropped messages due to wrong authentication check (i.e. wrong password), or dropped messages due to bad connection.

That will be an interesting read. Though not having a table of contents for a 117 page (double column!) report really isn't ideal..

- At least in computer science, it's generally professors who organise the peer review (the Program Commitee)

- I've heard from several collegues that the editor introduced spelling mistakes. Sure, overall they might get some errors out, but a spellcheck is not needed.

- Well yes. But there is no need for that to be expensive.

- Do we need them for this? If there really is fraud, previous cases show it's their university that starts an investigation. I'm not sure if the effect of retracting a paper is that significant..

- If all papers were public in the first place, there is no need to contact someone if it's okay to reuse material.

Anyway publishers might provide some value, but not enough to demand we pay for every single paper, or pay costly subscriptions. They need to die already or adept.