clarify comment about client pairing and ecdh_secret

This commit is contained in:
F. Duncanh
2023-09-02 13:25:55 -04:00
parent f1e05045c2
commit 26fb20a066

View File

@@ -397,12 +397,18 @@ raop_handler_setup(raop_conn_t *conn,
unsigned char ecdh_secret[X25519_KEY_SIZE];
if (pairing_get_ecdh_secret_key(conn->pairing, ecdh_secret)) {
/* In this case (legacy) pairing with client was successfully set up and created the shared ecdh_secret:
* aeskey must be hashed with it
* aeskey must now be hashed with it
*
* If byte 27 of features ("supports legacy pairing") is turned off, the client does not request pairsetup
* and does NOT set up pairing (this eliminates a 5 second delay in connecting with no apparent bad effects).
* This may be because uxplay currently does not support connections with more than one client at a time
* while AppleTV supports up to 12 clients, and uses pairing to give each a distinct SessionID .*/
* In this case, ecdh_secret does not exist, so aeskey should NOT be hashed with it.
* UxPlay may be able to function with byte 27 turned off because it currently does not support connections
* with more than one client at a time. AppleTV supports up to 12 clients, uses pairing to give each a distinct
* SessionID and ecdh_secret.
* The "old protocol" Windows AirPlay client AirMyPC seems not to respect the byte 27 setting, and always sets
* up the ecdh_secret, but decryption fails if aeskey is hashed.*/
if (logger_debug) {
char *str = utils_data_to_string(ecdh_secret, X25519_KEY_SIZE, 16);