# secretKey ⊕ (secretKey ≪ 1), is randomness lost?

A truly random secret key is run through a cipher

secretKey ⊕ (secretKey  ≪ 1)


is randomness lost? As in, is the computational cost to guess the ciphertext from secretKey ⊕ (secretKey << 1) lower than the cost to guess secretKey?

• Let's put it this way: if your secret key is cryptographically secure, you don't gain anything by applying such a shift-XOR. To clarify: for what reason would you want to do that anyway? I'm asking because in some scenarios that last, non-XORed (read: non-changing) bit might even introduce and represent a big problem. – e-sushi Mar 1 '18 at 18:16
• Why not do a logical shift like a modulo, so 1469 >> 1 becomes 9146 – lsh Mar 1 '18 at 18:22
• That still doesn't explain why you would do that? What are you trying to gain — or better — which (cryptographic) problem are you trying to solve by doing so? In the end, you're merely applying a cryptographically insecure permutation on a secret (with no entropy loss but no real cryptographical gain either). – e-sushi Mar 1 '18 at 18:34
• As e-sushi asks, what's the point? Are you trying to make a random secret key more secret? A little more detail might solicit a better answer. – Paul Uszak Mar 1 '18 at 21:35
• cryptographic operators that preserve randomness are interesting – lsh Mar 1 '18 at 22:04

While bmm6o's answer is correct, I want to give another angle onto things.

The function / transformation you described is linear! Specifically, it is a linear function over the vector space $\mathbb F_2^n$ if you consider $n$-bit inputs. Now this means, that you can apply all the tricks you learned in linear algebra to this transformation, which is characterized by the following matrix for $n=4$ (assuming $\ll$ denotes cyclic shift instead of logical shift):

$$\begin{pmatrix} x_1'\\x_2'\\x_3'\\x_4' \end{pmatrix} = \begin{pmatrix} 1&0&0&1\\ 1&1&0&0\\ 0&1&1&0\\ 0&0&1&1 \end{pmatrix} \cdot \begin{pmatrix} x_1\\x_2\\x_3\\x_4 \end{pmatrix}$$

If $\ll$ denotes logical shift (i.e. fill up on the right with 0 instead of what was pushed out), then simply replace the top-right $1$ with $0$.

As it turns out, if you have the top-right $1$, the determinant of the matrix is $0$ which also means, the transformation is not a permutation, as there's no unique inverse function!

However, if we use the version with a logical shift instead, we always get a determinant of $1$ and thus the confirmation that this indeed describes a permutation (and if we want to, we can also invert it).

To see the above assertions, let's call the matrix $A$ and the value of the top-right bit $b$. Note $A-I$ is the companion matrix to the polynomial $x^n-b$, which means the characteristic polynomial of $A-I$ is $x^n-b$. Now the characteristic polynomial of a matrix $B$ is equal to $\det(B-xI)$, which in our case is $\det((A-I)-xI)=\det(A-(x+1)I)$ which for $x=-1$ yields $\det(A)=(-1)^n-b$, however in $\mathbb F_2$, $-1$ is equal to $1$, meaning $\det(A)=1-b$, which implies that the key transformation is invertible (and thus entropy-preserving) iff a logical instead of a cyclical shift is used for all values sizes of the input and output! Credit goes to Will Jagy for the inspiration (and for a shorter, but more mathy explanation).

The function $f(x) = x \oplus (x << 1)$ defines a permutation:

000 -> 000
001 -> 011
010 -> 110
011 -> 101
100 -> 100
101 -> 111
110 -> 010
111 -> 001


So there is no loss of entropy.

• You are ignoring the high bit of $x \ll 1$ and assuming $x$ is a random number modulo a power of two rather than from some other set. – otus Mar 1 '18 at 19:11
• (Sure, it may not change the answer, but it does change the reasoning since it is not a permutation in general.) – otus Mar 1 '18 at 19:20
• The high bit may not be in $x \ll 1$, but it's still in x, and xoring them doesn't remove it. The whole function is therefore still a permutation. – Nova Mar 2 '18 at 23:53

If your secret key is cryptographically secure, you don't really gain anything by applying such a shift-XOR — but indeed, there is no entropy loss.

What's a bit unclear to me is why you would do that, or which (cryptographic) problem are you trying to solve by doing so.

In the end, you're merely applying a cryptographically insecure permutation on a secret… with no entropy loss but no real cryptographic gain either.

Depending on the specific scenario you might have in mind, let me drop a heads-up that using several outputs/derivations of a secret permuted this way can and will introduce attack vectors.

• The function could be used in a key schedule. Not wasting entropy is a pretty important factor for that. – Nova Mar 1 '18 at 18:57
• @Nova Sure, but there are better ways to cover that. – e-sushi Mar 1 '18 at 22:51

If by 'truly random secret key' you mean a sequence of random bits; and if you then XOR (exclusive or) those random bits with an equal amount of cipertext that was derived somehow from that secret key, I would say the result is also random.

This appears to be an example of a One Time Pad, where the ciphertext is the message and the 'truly random secret key' is the key. Given a random key the same length as the message, the output of a OTP is indistinguishable from a random value.

• This appears to be an example of a One Time Pad — No, because OTP expects both message and key to be the same length. In the case the Q describes, the last bit remains unchanged/unflipped 100% of the cases — which might or might not be considered as leakage of that last bit, or a 1-bit key repetition problem when projecting this onto an OTP scenario. This would be bad because the non-changing bit can be detected and exploited as an attack vector. (How successful such an attack would be merely depends on the length of the secret and the number of times that shift-XOR is repeated and applied.) – e-sushi Mar 1 '18 at 18:05