3 ms·
> 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 som
by 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.