Le tridi 3 messidor, an CCXXIV, Dan Purgert a écrit : > Because the TCP "stream" is still encapsulated in IP packets / Ethernet > frames, and you cannot simply "break" an encrypted block at some > arbitrary point in order to make it fit nicely in the packet / frame. Actually, this is exactly how it happens, you have to refresh your knowledge of TCP and the socket API. TCP offers applications a stream interface, the splitting into IP packets is done by the network and is invisible[*] to the application or, in our case the TLS implementation, and it can happen anywhere, including in the middle of cipher blocks. Therefore, cryptography adds no bandwidth overhead for a continuous stream, it only adds overhead when the streams stops for some amount of time due to the last incomplete packet. For discontinuous streams made of very short segments (VoIP, interactive typing), this overhead can become significant, but all the layers of the networking stack add their overhead, and the overhead due to crypto padding is rather in the low range, especially since applications that work that way will usually optimize their protocol to fill cipher blocks. Also, just to correct you all the way, note that the block size of most current block ciphers is 16 octets, not 64. [*]: almost: remember bad interactions between the Nagle algorithm and delayed ACKs.
Attachment:
signature.asc
Description: Digital signature