spieglt
commented
1 year ago I'm working on a new version and will probably bump the password length to 8 characters. Not sure if I'll put in longer custom passwords, I'll think about it. A longer password shouldn't have too much security implication: once the transfer is started, only one connection will be made. If an attacker shoulder-surfed the password or QR code (as the new version will have for connections involving Android/iOS), they'd be able to hijack the transfer, but it would be clear on the other device that it was not sending or receiving.
The encryption used in transit is AES-GCM. The password key-derivation function is scrypt, though this will likely be removed in the new version in favor of just SHA-256. I can't find a good version of scrypt or Argon2 in Kotlin, Swift, and Rust, and the new version will support Android.
A computationally-expensive key derivation function isn't actually necessary because nothing is being stored in encrypted form, so there's no hash to crack later. Additionally, all ad hoc WiFi connections made by Flying Carpet are protected with WPA2, so the data transferred is already encrypted. Why the second layer of encryption then, you might ask? Because when I first started this project in 2016 or so, ad hoc WiFi connections hosted by macOS didn't necessarily have any encryption, and I haven't bothered to change how it works since. Now, Apple doesn't let you run hotspots programmatically on macOS or iOS, so it's a non-issue. I'll probably leave the AES-GCM in for now, though may remove later if it improves performance significantly.
Thank you for the suggestion!
Will make longer random/custom password as an option? Like 16-digit or more. And I wonder know what encryption method it uses.