block cipher --> stream cipher
I'm wondering about the best way to pad a block cypher at the end of data.
The problem is I'm reading from a buffer into a block cipher that takes 8 byte chunks. I won't know how much data there is until I get to the end, and I'm writing to a buffer so I cand prepend a count when I get there. Now assuming (for example) I can only fill the buffer half way at the "end of data" I now have to pad it. When I reconstruct my data how will I know where the padding starts?
My solution was to write some predifined value at the end of data (say 0x01), then keep writing 0x00 untill at least 1 whole block is zeroes. This is bad for 2 reasons:
1. I have to check every byte on a decrypt to see if it's a 0x01 and then keep a buffer to see if the rest are 0x00, if yes ok, if not flush the buffer to the output and keep going. This is a waste of resources.
2. If anyone knew about this last chunk of 0x00, it weakens the security because it gives a potential attacker a plaintext/ciphertext pair.
So what's a fast, secure solution?
[1069 byte] By [
mgbolusma] at [2007-9-27 23:56:02]
Solution 1: Read up BITSTUFFING and use it in ur algorithm.
Solution 2: Since the interceptor cannot find out anything abt. the data (obviously), we can prepend the message with the length of the message. So, the message is Length;Data;Padding. Thus, u first read the length from the input, using that, get the data and thus, ignore the padding (if any). This is also a possible solution (though i personally prefer the bitstuffing method!).
Thanks for responding.
Personally I don't like option 2 because I'll have to know in advance how much I'm sending.
Also it does enable an attacker to guess or detect the plaintext values for the first few bytes. Consider the trade off: the more variable the padding length is, the more efficiency is lost (during large pads). If the padding variability is low (say 0<padlength><10) an attacker will know the plaintext of the prepended length data is one out of 10 possibilities, deduced from the length of the data.
Either way it's no good.
I'll look into bitstuffing.
What I've done in the meantime is fudged my Fiestel cipher implementation to be dynamically down-scalable in terms of the block size. This of course is only used in the last few bytes.
I don't know much abt. feistal n/ws but going by the number of flat keys existing for the network, changing the algo. to work for a smaller block size might actually compromise on security right? Also, once the last (smaller than usual) block is cracked, the same key would have been used for all the other blocks right? So, isn't this a drastic compromise? Check out other possible implementations.
