3 ms·
> From this key we derive a 128bit key using PBKDF2. We use the room name as a salt in this key generation. This is a bit weak but we need to start with informa
by ccktlmazeltov 7y ago
> From this key we derive a 128bit key using PBKDF2. We use the room name as a salt in this key generation. This is a bit weak but we need to start with information that is the same for all participants so we can not yet use a proper random salt.
1) You do not need to use a password-based KDF if your key is a random bytearray of >= 16 bytes. I expect that most people would use their feature by copy/pasting the key in email or whatever channels they're using to communicate the room link.
2) I'm not sure about IV generation, maybe somebody with more knowledge on SSRC/etc. can look at that
3) decryption error do not kill the connection, that's untypical but I think that should be fine
- phoe-krk 7y ago> 3) decryption error do not kill the connection, that's untypical but I think that should be fine I assume that this is so you can deal with the fact that some individual frames have been lost and/or corrupted as long as the next ones decrypt just fine. That is important for video streams; I can imagine that the quality of life of people using E2EE streams would suffer if the stream was highly vulnerable to corrupting even a single bit within any of the frames.
- ccktlmazeltov 7y agoIn practice a bunch of layers under the application one have checksums: UDP already has a checksum, IP already has a checksum too, the data link layer too... so maybe you wouldn't even reach a naturally corrupted AES-GCM ciphertext? Not sure what are the probabilities for the UDP checksum though.