Basically you need to map [0,255] to [1,255]? What are the other constraints?
Yes, and …I can’t think of any other constraint.
I am just playing around, really. I am trying to make some side-channel “hiding” for the xCORE (by XMOS) architecture, by letting the other 7 cores work or don’t work at the same time as some encrypting algorithm is running on one core. They would interchange on a cycle basis.
I’ll publish the code when/if I think it worth discussing. (This would be at Task/processes to insert random noise).
I ran into a problem that I think is a problem with the XMOS compiler. I have filed this to XMOS. But I thought it rather interesting, because then I was forced not to “hide” anything with all 32 bits being zero. That sound like a bad “fence” to me. Just one bit as “pole” would be better I thought. Kind of like a noise sender being switched off, even if zero is just as good a random number as any other.
And when I had a rather good random value (32 bits timer in ten nanoseconds resolution) snap-shot from a button I pressed it, I hoped to be able to not remove any of that nice randomness by setting a bit. (I guess this is a premise: that setting a bit destroys more than inverting a bit. XOR in theory does not lose any energy, and it’s therefore also a cipher. Anybody wanting to get these matters straight to me are welcome!) (Another premise I guess is that I did not think having any conditional test on the input set was a good idea. Also, is this a good premise…?) So I was trying with an xor, which would or would not invert bits. Then I in addition have shifted or not shifted the mask I am xor’ing with.
Still your idea triggered something One bit? When I made the xor-mask be only a single bit, bit number taken from the least significant 5 bits of the incoming random 32 bits bit_pattern, I then would invert bit number [0…31]. (For my case I needed to use only 8 bits, to always have a bit to invert.) And the mask would not be rotated for every of the 256 values I tested as the incoming data set. But I got the same result as xor’ing with anything else, any number of bits. Of 256 input values [0…255]:
128 values ok, 64 missed and then 64 counted two times. No zeroes.
There probably is something inherent in this algorithm that would map 1/4 of the data space over the other. So I get 50% unique numbers (call them “middle”) and 50% where I cannot tell if the mapped result orignally belonged to “left” or “right” data set. I can live with it. Maybe it’s even rather good.
I will not mark this thread as solve since I may come back with more here in due time. Or wait for some better idea!