Unfortunately not just with a straight "latch & 0xff" because the rndTab
array is 255 bytes, so every time latch is a multiple of 255 you end up
out of bounds. It would work if we could add a 256th byte to the
array. The comments suggest that there is an even statistical
distribution of the values in the s-box (rndTab) so I'm not sure I can
just pick a byte and drop it in there.
Let me see if there's another way to update latch that will be less cryptic.
--Jamil
On 09/21/2016 09:05 AM, Wang Weijun wrote:
I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little
difficult to understand. Does rndTab[latch & 0xff] also work?
Thanks
Max
On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote:
Hi Max and Xuelei,
Yesterday I also reached out to the SQE engineer who submitted the bug, asking
if this is an issue he's seen going forward from the original instance in 8u20.
He said that he hasn't seen this issue come up since the original bug
submission. Since the simple overflow condition is easily solved with my fix,
and the code has been otherwise stable I'd like to suggest that we keep the fix
as-is. The loop timing as it stands now is not the source of the bug, other
than that latch can overflow and that is solved in one line. If we want to
revisit this and improve the overall performance (though I haven't seen
evidence that there is a perf issue with this at all) then maybe an RFE is in
order. What do you think?
--Jamil
