jvanname (OP)
Member
Offline
Activity: 705
Merit: 51
|
|
November 18, 2023, 11:44:32 AM Last edit: November 18, 2023, 01:31:58 PM by jvanname |
|
Since Pooja did not get someone to quote it yet, instead of responding to Pooja, I will explain further how we will actually improve symmetric encryption by making everything reversibility friendly. For the rest of you, insulting others for their very advanced level of education is a very chlurmckish thing to do. Do not do that.
Reversibility not only adds security against side channel attacks, but reversibility also adds security against mathematical attacks.
Suppose that you want to encrypt data. A person who does not care about reversibility may want to use a Feistel cipher which is the thing to use if you want a function that is invertible but is not built from invertible components. In a Feistel cipher, the round function is of the form (x,y)->(y,f(x) XOR y). Now, let's compute f(x) using a reversible computer. In this case, from the input x, one will produce the desired output f(x) along with some garbage information G(x). In this case, the mapping (x,0)->(f(x),G(x)) will be injective since it will be computed reversibly. Now, the mapping (x,0)->(f(x),G(x)) is computed using a reversible circuit C, so instead of applying the round function (x,y)->(y,f(x) XOR y), one can apply the reversible circuit C to the pair (x,y) to get (x,y)->C(x,y). If (x_1,y_1)=C(x,y), then the mapping (x,y)->(y_1,x_1 XOR y_1) is a reversibility friendly version of the Feistel cipher round function (x,y)->(y,f(x) XOR y). The mapping (x,y)->(y_1,x_1 XOR y_1) is no more inefficient than the original round function (x,y)->(y,f(x) XOR y), but it is much more secure for several reasons.
1. The garbage bits G(x) should not be thrown away not only because this costs too much energy that can be used for side channel attacks, but these garbage bits also add confusion and diffusion. (x,y)->(y_1,x_1 XOR y_1) does not throw away these 'garbage' bits while (x,y)->(y,f(x) XOR y) does.
2. The mapping f(x) does not incorporate anything from y. This is bad because y could be used to scramble x up more. The mapping (x,y)->C(x,y) actually does use y to scramble the bits in the registers holding x more.
3. The mapping x->f(x) does not scramble the bits in y at all. On the other hand, the mapping (x,y)->C(x,y) may scramble the bits in y and add those bits in x.
We can make SHA-256 more secure by replacing all of the irreversible components with reversible components. We can do the same thing with AES.
The only real security disadvantage for fully reversible block ciphers is probably in the key expansion, and this disadvantage is only a minor issue that should be investigated but will probably not produce any security nightmares. But then again, a fully reversible key expansion can save memory so a fully reversible key expansion improves efficiency while decreasing security by an infinitesimal. For a truly reversible key schedule, instead of XORing the round keys k_0,k_1...,k_13,k_14 to the block, one should XOR the round keys k_0,k_1,...,k_6,k_7,k_6,...,k_1,k_0 to the block. In other words, one needs to reverse the key expansion process. Since the two instances of k_i are generally far away from each other, there should not be much interaction between one instance of k_i and the next one. Of course, this needs to be investigated. The increase in efficiency of a reversible key schedule even on an irreversible device should compensate for any security disadvantage.
I wonder if it is easier to make reversible computation hardware that is not exactly entirely energy efficient but instead uses reversible computing just to make the computation more resistant against side channel attacks. It would be great if we can have a preview of reversible computation if we can first get reversible computation for side-channel attack resistance. This will smooth out the innovation curve so that hardware manufacturers can incorporate some reversibility into their chips before they are capable of making everything energy efficient.
Reversible computing is the future.
-Joseph Van Name Ph.D.
|