We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I'm trying to test those lines:
https://app.codecov.io/gh/JuliaCrypto/SHA.jl/blob/master/src%2Fshake.jl#L84
SHA.jl/src/shake.jl
Lines 74 to 76 in 88e1c83
Lines 83 to 88 in 88e1c83
So I construct an input:
julia> using SHA julia> SHA.blocklen(SHAKE_128_CTX) |> Int 168 julia> SHA.shake128(codeunits("0" ^ 167), UInt(32)) |> bytes2hex "1350314219fb0728c65f0a9f560e70c402d63f1862f9f34555ce27828f5e0373" julia> SHA.shake128(codeunits("0" ^ 168), UInt(32)) |> bytes2hex "39ebc9a5df5c81a46d8a6f543326348695ff59d0dd10e020b53cb49a1c1532e4"
python output:
>>> import hashlib >>> h = hashlib.shake_128() >>> h.update(b'0' * 167) >>> h.hexdigest(32) 'ff60b0516fb8a3d4032900976e98b5595f57e9d4a88a0e37f7cc5adfa3c47da2' >>> h = hashlib.shake_128() >>> h.update(b'0' * 168) >>> h.hexdigest(32) '39ebc9a5df5c81a46d8a6f543326348695ff59d0dd10e020b53cb49a1c1532e4'
Notice that for the input "0" ^ 167, julia's output does not match python's. There might be a bug here. @immoschuett
"0" ^ 167
The text was updated successfully, but these errors were encountered:
Hi, thanks for the tests @inkydragon
I also thought about the padding.
I think the same issue is also in the digest for the other SHA3 hash functions. The padding of julia SHA is not along the NIST standards.
the Padding in the else case usedspace == blocklen(T)-1 should be
usedspace == blocklen(T)-1
context.buffer[end] = 0x9f for SHAKE_CTX
context.buffer[end] = 0x9f
I tested the new padding and the output matches the python output then.
and one can also change the padding in the digest for SHA3_CTX
context.buffer[end] = 0x86 for sha3 digest function, but this (probably) is ivariant in the transform. So one would not need transform twice
context.buffer[end] = 0x86
Sorry, something went wrong.
Fixed by #95
No branches or pull requests
I'm trying to test those lines:
https://app.codecov.io/gh/JuliaCrypto/SHA.jl/blob/master/src%2Fshake.jl#L84
SHA.jl/src/shake.jl
Lines 74 to 76 in 88e1c83
SHA.jl/src/shake.jl
Lines 83 to 88 in 88e1c83
So I construct an input:
python output:
Notice that for the input
"0" ^ 167
, julia's output does not match python's.There might be a bug here. @immoschuett
The text was updated successfully, but these errors were encountered: