please address
https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
Sure. As soon as someone creates http://en.wikipedia.org/wiki/Sunset_Shimmerso I can use an appropriate example.
Google also seems to be using RC4 128, so that explains why there's no padding by default there.
RC4 is a stream cipher. The more secure ciphers are (all?) block ciphers.
"A block cipher https://en.wikipedia.org/wiki/Block_cipher works on units of a fixed size https://en.wikipedia.org/wiki/Block_size_(cryptography) (known as a *block size*), but messages come in a variety of lengths. So some modes (namely ECBhttps://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 and CBC https://en.wikipedia.org/wiki/Cipher_block_chaining) require that the final block be padded before encryption."
On Fri, Aug 2, 2013 at 10:42 PM, James Salsman jsalsman@gmail.com wrote:
please address
https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
Sure. As soon as someone creates http://en.wikipedia.org/wiki/Sunset_Shimmerso I can use an appropriate example. _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Anthony, padding in this context means adding null or random bytes to the end of encrypted TCP streams in order to obscure their true length. The process of adding padding is entirely independent of the choice of underlying cipher.
In this case, however, we have been discussing perfect forward secrecy, which is dependent on the particular cypher. ECDHE-RSA-RC4-SHA is an example of a PFS cipher and TLS key exchange protocol choice widely supported by Apache supporting PFS.
The English Wikipedia articles on these subjects are all mostly start-class, so please try Google, Google Scholar, and WP:RX for more information.
On Fri, Aug 2, 2013 at 11:09 PM, James Salsman jsalsman@gmail.com wrote:
Anthony, padding in this context means adding null or random bytes to the end of encrypted TCP streams in order to obscure their true length. The process of adding padding is entirely independent of the choice of underlying cipher.
My point is that if the stream is encrypted using a block cipher (at least, in CBC mode), then it's already padded to the block size of the cipher.
That's the more complete answer to my question of "How much padding is already inherent in HTTPS?" HTTPS itself does not have any inherent padding, but when used with certain block ciphers, it does.
By the way, for most hours it's around 2.1-2.3 million, not 4.3 million. Wikimedia has been kind enough to give us a list of which pages are viewed each hour of the day, along with the size of each page: http://dumps.wikimedia.org/other/pagecounts-raw/
In this case, however, we have been discussing perfect forward secrecy,
which is dependent on the particular cypher. ECDHE-RSA-RC4-SHA is an example of a PFS cipher and TLS key exchange protocol choice widely supported by Apache supporting PFS.
PFS is the method of key exchange. You can use it with various different ciphers. From what I'm reading it can be used with AES and CBC, which would be a block cipher which pads to 128 or 256 bytes.
On Fri, Aug 2, 2013 at 11:33 PM, Anthony wikimail@inbox.org wrote:
AES and CBC, which would be a block cipher which pads to 128 or 256 bytes.
I mean bits, of course.
wikimedia-l@lists.wikimedia.org