4 ms·
Can someone with more knowledge expand on the bandwidth limitations here - what are the hard limits for TCP/sound? Are the speeds here technically able to impro
by Normal_gaussian 9y ago
Can someone with more knowledge expand on the bandwidth limitations here - what are the hard limits for TCP/sound? Are the speeds here technically able to improve marginally, significantly, or not at all?
- Piskvorrr 9y agoOne would think that you'll start hitting real-world limits real soon - background noise, speaker/microphone characteristics etc. Improving on those usually means more expensive equipment, this would be the most limiting factor IMHO.
- pja 9y agoHard limits are set by the strong absorption of ultrasonic frequencies by the air - IIRC the expected range of frequencies > 1MHz is measured in single digit cm & drops very rapidly. This reddit comment ( https://www.reddit.com/r/askscience/comments/3oo5ks/is_there_a_maximum_frequency_sound_that_air_can/cvz9xux/ https://www.reddit.com/r/askscience/comments/3oo5ks/is_there... ) quotes references that suggest a 100dB drop-off / foot @ 10MHz.
- eecc 9y agoMeh, if exfiltrating a couple kB of password data is all you need... the time for a coffee at a Starbucks is probably enough already
- cdoxsey 9y agoSound can be used as part of a handshake process and then real communication done over the internet: https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...
- amelius 9y agoThat could be nice to setup/connect devices that don't have buttons and a display. E.g. connecting a printer to a tablet, sending wifi passwords to the printer. (At least, as long as nobody else is listening).
- gambiting 9y agoIsn't that solved by RSA? Printer broadcasts its public key saying "hey, printer here, send me the wifi password please". Your phone uses the printer's public key to encrypt the wifi password and send it out. The attacker cannot snoop on the key, because it doesn't have the printer's private key necessary to decrypt the message.
- Cyph0n 9y agoAn attacker could still man in the middle the initial key handshake. Printer: "Printer here, my pubkey is A" Attacker (races phone): "Alright bro, I got it" Attacker: "Printer here, my pubkey is B" Phone: "Alright bro, I got it" Phone: "Here is the WiFi password, encrypted with B" Attacker: "Thanks!" This example is pretty simplistic, but the idea still works even if there is some form of authentication (e.g., challenge-response). The way around this is to pre-share some sort of info to verify the authenticity of any new incoming key. For example, the user downloads a printer app on their phone that contains a master pubkey. On the other side, the printer would have a device pubkey signed with the master private key. When the phone receives a new printer message, it first veriffies the key signature to ensure that it actually came from a legitimate printer. If you can't get some sort of key onto the phone, your best bet is to perform key exchange out of band. One common technique for phones is NFC: it requires proximity, making the attack above difficult to execute.
- zokier 9y ago> For example, the user downloads a printer app on their phone that contains a master pubkey. On the other side, the printer would have a device pubkey signed with the master private key. When the phone receives a new printer message, it first veriffies the key signature to ensure that it actually came from a legitimate printer. To further increase security, the certificate (signed pubkey) presented should also contain some unique per-device identifier (serial number or some PIN code or something). Otherwise attacker could possibly extract keys from a similar device to conduct the attack.