Use Cases
Instances where an fcast receiver is on a publicly-accessible wifi network, such as conference presentations, university lectures, digital signage applications, etc
Proposal
I think that the protocol should add uint8_t header field mac in order to indicate the presence of a 3rd message field: a message authentication code.
This field could contain a keyed digest as a way to prove that the sender has the same password as the receiver. When the receiver receives any packets (implementation of this would likely go within TcpListenerService.ts as a simple wrapper), it should compute the MAC and compare to the provided value to ensure that the proper password was used. To generate the MAC key from the user provided password, a key-derivation function such as PBKDF2 should be used (this can be precomputed on server start and stored rather than storing the actual user provided password). This would make packets look something like this:
{
"size":<num>,
"opcode":<num>,
"mac":1
}
{
<body contents here>
}
HMAC-SHA256(<header+body>, PBKDF2(<password>))
References
No response
Use Cases
Instances where an fcast receiver is on a publicly-accessible wifi network, such as conference presentations, university lectures, digital signage applications, etc
Proposal
I think that the protocol should add
uint8_theader fieldmacin order to indicate the presence of a 3rd message field: a message authentication code.This field could contain a keyed digest as a way to prove that the sender has the same password as the receiver. When the receiver receives any packets (implementation of this would likely go within
TcpListenerService.tsas a simple wrapper), it should compute the MAC and compare to the provided value to ensure that the proper password was used. To generate the MAC key from the user provided password, a key-derivation function such as PBKDF2 should be used (this can be precomputed on server start and stored rather than storing the actual user provided password). This would make packets look something like this:References
No response