# Re: byte inversion in ciphertext

"Joseph Ashwood" <ashwood@xxxxxxx> wrote in message
news:LvCdnf7oS5BUV6jbnZ2dnUVZ_uygnZ2d@xxxxxxxxxxxxxx
Actually the attacker will be able to narrow it down rather effectively. I
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
Joe you are as always informative descriptive and overall very helpful,
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.

.

## Relevant Pages

• Re: byte inversion in ciphertext
... using a variation of JT's idea of obfuscating the ciphertext. ... starting at point a invert the byte ... ascii value of point b xor ascii value of point a ...
(sci.crypt)
• Re: Authenticating encrypted messages?
... > therefore any change in the ciphertext cancels out and leaves ... if one uses modular addition in place of XOR. ... In my follow-up to Gregory Rose, I wrote "using the modular ... sum of all preceding ciphertext and plaintext blocks ...
(sci.crypt)
• Re: verify symmetric cipher key?
... the ciphertext is intact: proceed to step 2. ... WRONG decryption key was used, so the decrypted text is useless. ... a MAC. ... I have a few hundred bytes of data to encrypt with a user passphrase. ...
(sci.crypt)
• Re: Research into PRFs versus research into PRPs
... Instead of XOR you can also just overwrite. ... plaintext with the ciphertext via XOR due to the MMO chaining mode. ... With a bigger permutation, this is not ... Merkle-Damgård (and also Sponge) constructions. ...
(sci.crypt)
• Re: Help me understand Tweakable Block Cipher / LRW
... >encryption. ... XOR the computed value hwith the ... Why is the ciphertext further processed by ... theory or theoretical computer science. ...
(sci.crypt)