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.
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!
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.
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.
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…
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.