Topic: Reversible computation promises cryptographic strength instead of weakness. (Read 145 times)

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.

I have no idea why you have such an aggressive and vulgar behavior just because someone disagreed with couple of your posts (even if you think it is a mistake). Unlike you I never claimed to be right, smart or an expert; nor did I ever feel the need to advertise my academic degree in every post I make!

A lot of things could have been but they are not. Like Bitcoin that is not using AES!

The hash function in Bitcoin is used for a lot more than just mining and it needed to be efficient. Something like AES doesn't even make sense to be used in many of those contexts.

SHA-2 algorithm uses the compression function of Davies-Mayer not a cipher.
None of it warrants using the term "encryption" for hash algorithms like SHA-2 though.

Case of IOTA is what happens when one tries to re-invent the wheel and creates their own cryptography function instead of using existing ones that are reviewed by many experts and are battle hardened already.
Besides if you want to talk about vulnerabilities in an algorithm used by an altcoin, there is a different board for it and you should be specific since in Bitcoin we only use SHA-2 and it doesn't have such vulnerabilities.

Keeping the message doesn't change the fact that hash algorithms do not map messages to distinct digests.
The hash algorithms do not guarantee distinction either hence they are not injective. The only thing they guarantee is that finding a collision is difficult, otherwise according to Pigeonhole Principle collision is guaranteed. Even without the Pigeonhole Principle, the underlying algorithm doesn't guarantee "distinct mapping" to be referred to as injective.

pooya87-I am responding to your comment only because someone has quoted you (I am otherwise ignoring you). Your comment has very little substance to it, so please learn more about mathematics before trying to pretend that you are smarter than me. The only thing that you are doing by talking that way is displaying your abhorrent attitude and complete and total lack of social awareness. Please get help. Or don't. It is not my problem.

0. Bitcoin could have just as easily used AES for its mining algorithm. There is no fundamental reason that Bitcoin needed to use a cryptographic hash function rather than a block cipher for mining.

1. SHA-256 is constructed using an encryption function. This is called the Davies-Meyer construction. There are several ways of constructing cryptographic hash functions from block ciphers including the Davies-Meyer,Matyas–Meyer–Oseas, and Yaguchi–Preneel constructions. You can find descriptions of these constructions in the book Cryptography: An Introduction (3rd Edition) by Nigel Smart. Since block ciphers are invertible, these cryptographic hash functions are built from invertible components.

2. The fact that cryptographic hash functions are not injective is irrelevant for several reasons. For energy efficient reversible computing, one should seek PARTIAL REVERSIBILITY instead of full reversibility. Cryptographic hash functions are naturally partially invertible functions because collision resistance is a weakened version of invertibility. And those who are unfortunate enough to not use enough invertibility in the construction of their hash function will inevitably produce either an insecure or inefficient cryptographic hash function (this is what happened to Iota's hash function CURL). Invertible components are NECESSARY for constructing secure cryptographic hash functions.

3. When computing the hash of something, do you always delete the file that you are hashing? If you do not, then you are running the procedure x->(x,H(x)) which is injective while the procedure x->H(x) is not injective.

-I do not care how you access the article. Just read it. Or don't. And no, I do not get commission from this. I am citing the article because it supports the notion that full reversibility (without uncomputation and deletion) is needed in order to create ciphers that are more secure against side-channel attacks. By making a cipher more energy efficient using reversible computation, the cipher will leak less information to the outside, so it will be safer against side-channel attacks. Do you have anything that is insightful to say or are you just going to hate people who cite articles? If you want to complain about how much it costs to read an article, please start another thread because that is OFF-TOPIC.

-Joseph Van Name Ph.D.

^Basically this.

Also, 40 bucks for an article that you can read for free on Sci-Hub? Lol what a steal. Does OP get an affiliate commission or something?

Why do you still struggle to understand the difference between "encryption" which by design is and has to be reversible and "hash algorithm" that by design is not reversible?
By the way in Bitcoin we do not use any kind of encryption whatsoever. So even bringing it up using AES in context of Bitcoin is irrelevant.

Some people here have been needlessly worried that a reversible version of the advanced encryption standard would have resulted in a cryptographically weak encryption function. First of all, before standardizing a cryptographic function, the cryptographic community would perform extensive tests against that cryptographic function to see it it has any weaknesses. Second of all, reversible computation offers a natural resistance to side-channel attacks against encryption including power attacks. If I were encrypting something using the AES encryption function, I would not be concerned at all about any mathematical weakness with the AES, but I would instead be worried about side channel attacks.

https://link.springer.com/article/10.1007/s00542-019-04581-2

Since reversible computation makes encryption both more efficient and more secure, I am bamboozled by the cryptographic community's failure to standardize a reversible block cipher. They should have standardized reversible versions of AES,SHA-256 back in 2002. They are now about 25 years late, and they will continue to get later and later.

-Joseph Van Name Ph.D.