5 ms·
A standard public-key encryption strategy would work if the key was generated on each client (instead of being handed over the air from the router in plaintext
by alanh 16y ago
A standard public-key encryption strategy would work if the key was generated on each client (instead of being handed over the air from the router in plaintext as you assume). This is exactly how HTTPS works — otherwise HTTPS would be completely susceptible to a man-in-the-middle attack
- dkarl 16y agoHTTPS is susceptible to a man-in-the-middle attack if clients don't validate certificates. To ensure you weren't connecting to a rogue access point in some hacker's backpack, every access point would need a certificate that you could verify via a trusted third party, just like certificate authorities such as Verisign verify Google's SSL cert so you known you're talking to Gmail instead of an imposter. It would be a nightmare to administer such a service using the current means of identifying access points (SSIDs). Who would be allowed to register a certificate for joescoffeeshop?
- jimmyk 16y agoSince nothing like https exists yet for public wireless networks, it could be made so that when the client connects and the access point sends the client its public key, the public key shows up (or preferably doesn't show up but can be made visible) on the client's computer which can be then verified against a sign in the store if the client really cares. You don't need an outside authority when you basically trust the coffee shop.
- Someone 16y agoI think that would work (if the sign in the store is physically safe), but I also (pedantically) think that would not satisfy the "without a shared key" part of the original question. Thinking about this: publishing your public key on a bar code printed on a wall might be a better solution, if the world would be used to that. It would enable your computer to compare the public keys sent over the two channels (visible light and WiFi)