Am 22.07.2014 17:10, schrieb scott:
>> I've seen a simple encryption like this:
>>
>> uint64_t poor_encrypt(uint64_t x)
>> {
>>      x = x ^ SECRET1;
>>      x = x * SECRET2;
>>      x = x ^ SECRET3;
>>      return x;
>> }
>>
>> the decryption is just the reverse:
>>
>> uint64_t poor_decrypt(uint64_t x)
>> {
>>      x = x ^ SECRET3;
>>      x = x * INVERSE_OF_SECRET2;
>>      x = x ^ SECRET1;
>>      return x;
>> }
>>
>>
>> How many "x, encrypt(x)" pairs are necessary to reveal the 3 secret
>> constants? I think, 3 pairs should be enough, but am I right?
> 
> I think it depends what you mean by "reveal".

A way to tell me the 3 SECRET constants. Dumb brute force is AFAIK
impossible for 3 64 bit constants, so a little bit of thinking is
necessary to shrink the search space. And the more thinking you invest
the smaller might be the search space, at best it is shrunken to only
one triple. :-)

It is a trade-off in the algorithm. ;-)

> If you mean, can you
> "solve" the equations to find SECRET1-3, in the same way you would a
> mathematical equation, then it might not be possible without some
> element of brute-force. For example how do you solve (x*5)^(x*10)=49
> (where * and ^ are 8-bit CPU integer multiply and xor)?

For 8 bit numbers I'd just make a brute-force scanniing, no more mental
efforts are necessary here. Your x is 99. That's the only solution. :-)

> The other question is, given the 3 pairs, is there a unique set of
> SECRET1-3, or could a different set allow the same pairs?

Right. How many pairs are necessary so the 3 SECRET constants are unique
and definite?

Lars R.

Post a reply to this message