# Re: byte inversion in ciphertext

*From*: "Antony Clements" <antony.clements@xxxxxxxxxxxxxxx>*Date*: Tue, 1 May 2007 00:41:07 +1000

"Joseph Ashwood" <ashwood@xxxxxxx> wrote in message

news:LvCdnf7oS5BUV6jbnZ2dnUVZ_uygnZ2d@xxxxxxxxxxxxxx

Actually the attacker will be able to narrow it down rather effectively. IJoe you are as always informative descriptive and overall very helpful,

will assume a block cipher in CBC mode, the attacker Eve performs a

decryption, resulting in a large expenditure of work. Eve observes where

the plaintext stops making sense, this gives a window for n, with AES the

window would be 16 long. The resulting complexity change from this is

linear in the size of the cipher block at best. With stream modes (e.g.

CTR) and stream ciphers it gets worse, Eve only have to observe exactly

where it breaks down giving a window of length 1, at worst doubling the

complexity, and in the case of CTR mode generating a complexity

differential of epsilon for very small epsilon.

Whether this has any value depends on how close to the line you are

getting in your security, if the difference between 2^128 and (2^128)+50

makes a difference then it is absolutely of use, but such situations are

unusual at best. You would actually be better served by performing a

random blinding using a chosen value V similar to:

for i=1 to k

piece[i] = piece[i]+V

rof

inversion of this is trivial, and again it offers at most a small linear

improvement in the length of V, but the effect is more dependable. For

further increases the blinding performed in DES-X would be more effective.

All of these are at best considered stop-gap measures with limited useful

ranges of operation, and it can be argued that they are of no real

cryptographic use.

Joe

thanks again.

now to annoy some people slightly, sorry in advance.

the sequence i am using at the moment is as follows

where i indictates the block number, n indicates the random inversion points

and N is a large odd number, K is the length of m and K2 is 512 bits

for each block

invert Pi

Ci = Pi xor K xor N xor Ci-1

invert Ci

pbox1 -6 */the Pboxes essentially just reverse the block so that the last

byte is first etc/*

Ci = Ci xor K2

recalculate N

split the block into two equal parts and swap positions */partB & partA as

opposed to the original block of partA & partB/*

rof

randomly invert every n bytes of C */that is the entire ciphertext not the

block/*

so if k is the length of the ciphertext then if the ciphertext is 384 bytes

in length, then n will be between 1 and 383

this means that if n is 15 then bytes 15,30,45,60,...,375 will be inverted

(decimal points are cut off), which bytes are inverted is not tied to the

size of the block but to the size of the ciphertext. alternately a random

byte per block could be inverted, but that would be a lot more difficult to

implement and manage properly.

for your method of piece[i]+V where V is a pre-chosen value, unless the

coder is cutting off all decimal points then there would have to be some

sort of wrap around so that if piece[i]+V is outside the bounds of k, that i

will equal (i+v) - l(C)

for the method i am currently experimenting with the decryption is as

follows (as viewed by an amateur attacker for an amateur cipher)

discover the value of n

invert every n bytes of the ciphertext

swap the block back

Pbox 1-6

invert Ci

Ci = Ci xor K xor N xor Ci-1

invert Ci

Pi = Ci xor K2

recalculate N

given that the decryption is rather trivial, the amateur attacker needs to

find the value of n, the value of K and K2 and the value of N, finding the

value of K2 will take roughly 2^256 tries because K2 is a 512 bit value

(2^n/2). fnding n will take (k/2)-1 tries where k is the length of m because

the ciphertext has bit inverstions not the plaintext. so a full decryption

with a correct N, K and K2 will be needed to find out which bytes of the

plaintext are incorrect. finding K will take an amateur attacker 2^k/2

attempts.

even if K, K2, and N are discovered, the plaintext will increasingly become

jibberish because the location of the inverted byte n, has not been

discovered and is not a constant. staying with the value of 15, in the first

block bytes 15,30,45and 60 will be inverted. block 2 will have bytes

11,26,41 and 56 inverted. and given that this is in CBC mode block 2 will

not decrypt properly without knowing the inversion points in block 1.

.

**References**:**byte inversion in ciphertext***From:*Antony Clements

**Re: byte inversion in ciphertext***From:*Joseph Ashwood

- Prev by Date:
**Re: Ada Encrypts_2** - Next by Date:
**Re: Looking for an article written by Chor, B., Goldwasser, S., Micali, S. and Awerbuch, B** - Previous by thread:
**Re: byte inversion in ciphertext** - Index(es):