You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have conducted a review of the cubehash implementation with regard to the specification and found what I believe to be several bugs in the implementation. I will list them with a short description and supply further information below.
No 0-padding of the message to a 32 multiple.
Wrong size of hex digest string for small numbers in state.
Wrong application of transform.
The specification on http://cubehash.cr.yp.to/ says "Implementations restricted to byte-aligned messages can simply append a 128 byte and then the minimum possible number of 0 bytes to reach a multiple of b bytes"
As far as I can see b = 32. The 128 byte is added to the string here https://github.com/RndPhrase/cubehash.js/blob/master/cubehash.js#L84 however the message is not padded to a multiple of 32 before it is XORed into the state array.
When the bytes in state are small, the hex digest needs to be prepended with 0es. I found the integer 5427167 to yield a hex string 52CFDF. It is not incorrect, but I believe that the correct version is 0052CFDF.
Finally, the transforms are applied continuously on the message. The specification says "It xors the first b-byte input block into the first b bytes of the state, transforms the state invertibly through r identical rounds, xors the next b-byte input block into the first b bytes of the state, transforms the state invertibly through r identical rounds, xors the next b-byte input block into the first b bytes of the state, transforms the state invertibly through r identical rounds, etc. "
First there is an actual typo in the code, so only the entire initialization vector is applied only to the first byte of the state. Furthermore, the implementation is wrong for messages over the size of 32 characters as the block should then be XORed into the state before transform is called.
I have made a pull request that should fix all of these errors, I would like somebody to review them before merging.
The text was updated successfully, but these errors were encountered:
I have conducted a review of the cubehash implementation with regard to the specification and found what I believe to be several bugs in the implementation. I will list them with a short description and supply further information below.
The specification on http://cubehash.cr.yp.to/ says "Implementations restricted to byte-aligned messages can simply append a 128 byte and then the minimum possible number of 0 bytes to reach a multiple of b bytes"
As far as I can see
b = 32
. The 128 byte is added to the string here https://github.com/RndPhrase/cubehash.js/blob/master/cubehash.js#L84 however the message is not padded to a multiple of 32 before it is XORed into the state array.When the bytes in state are small, the hex digest needs to be prepended with 0es. I found the integer
5427167
to yield a hex string52CFDF
. It is not incorrect, but I believe that the correct version is0052CFDF
.Finally, the transforms are applied continuously on the message. The specification says "It xors the first b-byte input block into the first b bytes of the state, transforms the state invertibly through r identical rounds, xors the next b-byte input block into the first b bytes of the state, transforms the state invertibly through r identical rounds, xors the next b-byte input block into the first b bytes of the state, transforms the state invertibly through r identical rounds, etc. "
First there is an actual typo in the code, so only the entire initialization vector is applied only to the first byte of the state. Furthermore, the implementation is wrong for messages over the size of 32 characters as the block should then be XORed into the state before
transform
is called.I have made a pull request that should fix all of these errors, I would like somebody to review them before merging.
The text was updated successfully, but these errors were encountered: