BigInteger changes breaking RSAKey?


#1

Hi after a bump i’ve started to get wrong decryption of keys using RSAKey, previous keys are now useless and decryption cannot be made. Are you sure you double checked the consistency of the BigInteger changes you did recently ? I would prefer to avoid recompute and resend all client keys with the changed RSA encryption…

I can confirm that rolling back to the previous BigInteger implementation alone makes things to work again.


#2

That’s strange - obviously we have unit-tests for both BigInteger and RSAKey, and I was very careful to make sure nothing failed… If you can post some code that goes wrong, I’ll sort it out right away!


#3

Basically i have a key generated with the old classes that is not more valid with the new classes. I will send you everything.


#4

Can you share your example ? I have contributed to these classes in May 2016, the mistake is maybe on my side, even if I did a lot of tests before submitting too.


#5

I confirm it is broken for me too.
But IvanC had sent me his BigInteger code to test (before it was slightly edited and included in juce), and it works fine with it.
I don’t have time to look more into it right now unfortunately, but that might help figuring out where’s the issue.


#6

FYI we’re sorting this out today… Will post a fix soon!


#7

Jules > My investigation right now has shown me this : if you do 11 % 1 with BigIntegers, you get 1 instead of zero. I think solving this issue will solve all the others…

BigInteger test1(11), test2(1), test3(0);
test3 = test1 % test2;

#8

Got you M**********r !

in the function shiftRight, it’s :

instead of

Doing so make my activation code with RSA works again in a lot of different cases.

As a side note, I think I really hate that instruction :

for (int i = exp.getHighestBit(); --i >= 0;) 

That sounds clearer to me :

for (int i = exp.getHighestBit() - 1; i >= 0; i--) 

I did a mistake because of this :slight_smile:


#9

Sorry if this is completely unrelated, but I have a hunch that the new BigInteger also causes a bug in AudioDeviceManager.

If I set outputs 1+2, 3+4 active and get the state XML, the XML shows audioDeviceOutChans=“111”. (And obviously when recreating the manager state, the last channel goes inactive.) If I roll back the Juce source back so that the old BigInteger code is used, the written XML will have audioDeviceOutChans=“1111” which I suppose is correct and seems to reactivate the desired output channels later when loading the state.


#10

Xenakios > can you try my change in the BigInteger class, and tell me if the issue is gone ?


#11

Yes, that seems to fix the issue!


#12

OK I’ve pushed this one to develop. Kudos for spotting the mistake, I spent about 2 hours trying to find that bug :-).