This isn't my specialty, but I'm interested in cryptography. Here goes: When an iCloud user is created, a keypair is generated. The private key is stored in th

This isn't my specialty, but I'm interested in cryptography. Here goes: When an iCloud user is created, a keypair is generated. The private key is stored in the user's keychain; the public key is pushed to iCloud's server and placed in a central directory. Public keys of all of the user's contacts are cached locally on the device. When Alice opens her phone to share something via AirDrop, it polls available devices over BTLE. The polling message contains a nonce. Bob's device responds with a message containing two values: a nonce of his own, and a hashed+signed payload: (ecdsa_sign (bobs_private_key, (sha256_hash (concat alices_nonce, bobs_nonce)))) Alice's device computes the hash of the nonces, then iterates her contacts to find the one whose public key verifies the signature. This approach defeats a precomputed attack by including a nonce from both parties - a rainbow can't be generated for all transactions, only this one in particular. It does not expose Bob's identity, because all that is transferred is a (random) nonce and a signed message. The main drawback I see here is that when adding a contact, you have to download their public key from iCloud before you can share with them - so two devices cannot use AirDrop if they are not online, if they have not been online since the contact was added. As a workaround, you could set a flag when unsynced contacts are present and show a dialog if an AirDrop poll is detected before syncing occurs. In that case, you could fall back to something more closely resembling the currently implemented protocol, which would at least limit the data leakage present today to an edge case that requires explicit approval by the user.