Wither Air-Sea Battle

[c1ue]

Re: Wither Air-Sea Battle

Encrypting of video (or any other data) only trivially increases the size of the sent data.

I could believe this statement if the breakup of the data for encryption and streaming used the same restitch scheme. As I note above - this is certainly possible but would seem to add potential vulnerability.

Perhaps you can speak to that specific issue rather than make blanket comments.

For example: if the video stream is 128 bit but the encryption is 256 bit, then I'd think the headers would pretty much be automatically different.

If that weren't the case, then things such as VPNs and YouTube-over-HTTPS would be prohibitively bandwidth-expensive compared to running things in plain text; they are not.

This seems a completely unsupported statement. Can you perhaps point to some actual data?

I'd also note that the question of just how encryption increases data size is also unanswered. I've seen a number of posts where people in real life have seen significant data size increase after encryption:

http://www.experts-exchange.com/Secu..._26887362.html

I have seen that if I use 256 bit key, a 1 byte to 15 byte data becomes 24 bytes after incryption, 16 byte becomes 44, 100 byte becomes 152, 1000 bytes become 1344 etc.

This anecdote does seem to indicate that the overhead does not scale linearly with the amount of data, but in the case of data breakup for streaming - there would seem to be some specific upper limit to which the data is broken down to.

[Milton Kuo]

Re: Wither Air-Sea Battle

I could believe this statement if the breakup of the data for encryption and streaming used the same restitch scheme. As I note above - this is certainly possible but would seem to add potential vulnerability.

Perhaps you can speak to that specific issue rather than make blanket comments.

For example: if the video stream is 128 bit but the encryption is 256 bit, then I'd think the headers would pretty much be automatically different.

While I know practically nothing about video encoding, I don't see how there is going to be a correlation between 128-bit video (I don't know what 128-bit video means) and length of a cryptographic key. For the purposes of my statements, I view video as a blob of bytes that is treated no differently by a cipher than a very large chunk of text blob of bytes.

The talk of "stitching" is perhaps where the confusion lies. Encryption of video (or any large chunk of data) would rely on a streaming cipher which by its nature will only be able to process a subset of the entire message at any moment. The "stitching" together is done through a feedback mechanism of using the previous block's cipher text as an input into the encryption of the current block. The "headers" are thus different each time for each block and an attacker would have to chain his way back all the way to the initialization vector as one way of breaking the cipher.

The above is described in the standard/generally accepted cryptographic literature. I'm no cryptanalyst so I have to rely on the writings of those who are but the cryptanalysts say that using ciphers such as TDES, Rjindael, etc. is secure and mathematically hard to break. The literature out there also state what the expected length of cipher text is for a given plain text. So when I say that the size of the cipher text is only trivially larger than the size of the original plain text, it is based on both empirical observation in additional to the technical papers that describe the operation of the ciphers.

This seems a completely unsupported statement. Can you perhaps point to some actual data?

I'll write up a short program and list the source code here and you can see and try for yourself. I'll try to do that some time this evening when I've got a bit more time.

I'd also note that the question of just how encryption increases data size is also unanswered. I've seen a number of posts where people in real life have seen significant data size increase after encryption:

http://www.experts-exchange.com/Secu..._26887362.html



This anecdote does seem to indicate that the overhead does not scale linearly with the amount of data, but in the case of data breakup for streaming - there would seem to be some specific upper limit to which the data is broken down to.

The above question from Experts Exchange was submitted by a tyro who, like many people in the software industry, is utterly hopeless. In other words, it's utter tripe and he would not have asked such a silly question if he had spent 30 minutes to read the documentation.

To be certain, if you take a message and break it down into many sub-messages and encrypt each of those sub-messages individually with its own initialization vector and padding, you're going to have a fairly substantial difference in size between the original plain text and the cipher text. Something on the order of what you originally stated or even greater. However, to encrypt information in such a fashion is not how it's done by the professionals. For a reasonably small message relative to key length, it is entirely adequate to use one IV and one padding to encrypt the entire message, incurring only mere bytes of overhead.

Doing what the person on Experts Exchange asks is somewhat analogous to choosing an IP MTU of 68 bytes and then transferring a multi-megabyte file. You're going to get a lot of header overhead by splintering the data an unnecessary number of times and transmitting far more IP packets than necessary versus just using a larger MTU.

[Milton Kuo]

Re: Wither Air-Sea Battle

I'll write up a short program and list the source code here and you can see and try for yourself. I'll try to do that some time this evening when I've got a bit more time.

... and attached is a program written in C# against Microsoft's .NET Framework. If anyone is still reading this , the program can be compiled using the following command (assuming one has the .NET Framework installed):

csc.exe /target:exe /out:Encryptor.exe Encryptor.cs

The attached source code file should be renamed Encryptor.cs; files with an extension of .cs are disallowed by the vBulletin software.

If you run this program against various files types (video files, highly-compressible text files, compressed files such as .ZIP, audio files such as MP3 or WAV) with various sizes, you'll see that the cipher text is at most 16 bytes (padding which is up to a key size in length) larger than the plain text.

This is exactly the overhead you'll see used commercially and in military applications. Many of the commercial, on-the-fly hard drive encryption products also use the cipher I use for the attached sample program: Rjindael.