BTW, when encrypting 999 with radix {9,9,9}, this just break the protocol.
No matter which seed, decrypted 110 always happens:
999 (original)
230 (encryped)
110 (decrypted)
Last edit: Michiel van Grinsven 2017-05-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is true for every number that is max for the radix range:
888 (max for radix {8,8,8})
461 (this one differs from seed to seed)
110 (this one is always the same)
Last edit: Michiel van Grinsven 2017-05-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for getting in touch. Yes, there's a bug, but it might not be what you thing it is.
For the radix array { 6, 10, 10 }, the input array { 6, 4, 7 } is actually invalid.
As described in the documentation, the input array X is "a plaintext vector of length(W) integers such that 0 ≤ X[i] < W[i]," where W is the radix array.
In this case, the value of X[0] is equal to the value of W[0], which is out of the permitted range.
In fact, you should have gotten an exception for the inputs you provided, and there was a typo that let the inputs through. I've fixed that and added a unit test for this case.
I'll check the source in later today. Thanks for helping me find the bug!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In other words, when encrypting 999 with radix {9,9,9}
this translates the same as 099. There is a collision in
the protocol.
BTW, when encrypting 999 with radix {9,9,9}, this just break the protocol.
No matter which seed, decrypted 110 always happens:
999 (original)
230 (encryped)
110 (decrypted)
Last edit: Michiel van Grinsven 2017-05-10
This is true for every number that is max for the radix range:
888 (max for radix {8,8,8})
461 (this one differs from seed to seed)
110 (this one is always the same)
Last edit: Michiel van Grinsven 2017-05-10
Thanks for getting in touch. Yes, there's a bug, but it might not be what you thing it is.
For the radix array { 6, 10, 10 }, the input array { 6, 4, 7 } is actually invalid.
As described in the documentation, the input array X is "a plaintext vector of length(W) integers such that 0 ≤ X[i] < W[i]," where W is the radix array.
In this case, the value of X[0] is equal to the value of W[0], which is out of the permitted range.
In fact, you should have gotten an exception for the inputs you provided, and there was a typo that let the inputs through. I've fixed that and added a unit test for this case.
I'll check the source in later today. Thanks for helping me find the bug!