mirror of
https://github.com/morgan9e/UxPlay
synced 2026-04-14 00:04:13 +09:00
clarify comment about client pairing and ecdh_secret
This commit is contained in:
@@ -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);
|
||||
|
||||
Reference in New Issue
Block a user