search

jmoles / keccak-verilog

A Verilog (specifically, System Verilog) implementation of the not-yet-finalized SHA-3 winner, Keccak.
MIT License
8 stars 9 forks source link

Hash value from simulation not match online keccak-256 calculation. #2

Open etam89 opened 3 years ago

etam89 commented 3 years ago

HI, I might got it wrong. it seems to me that the hash value it got doesn't match the one shown online: in particular, on the first vector, the input is 128 Byte: AED66CE184BE232900000010F149905200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000 The output from verilog is: 0x9709bcc8... But the online keccak calculation from multiple sites gives: 54e334e78b4895ae9de75c36a2f5688262abfffe5139dc9e8cdc9d5ed5fae518 I try both big endian and little endian byte for the input. The simulated result doesn't match the one shown online. What am I missing?

Thanks! Eugene

jmoles commented 3 years ago

Been a few years since I've looked at this code. May take me a few days to get my environment up and running again to give it a look.

Have you tried any of the other test vectors in test_vectors? Do they also yield a different result?

etam89 commented 3 years ago

Thank you. Yes other test vectors has the same issue. it doesn't seem big endian/little endian issue.  I tried both way and the results don't match.BTW, one of the online site is:  Keccak-256 Online

Keccak-256 Online

Keccak-256 online hash function |

|

|

On Saturday, April 3, 2021, 05:13:47 PM PDT, Josh Moles ***@***.***> wrote:

Been a few years since I've looked at this code. May take me a few days to get my environment up and running again to give it a look.

Have you tried any of the other test vectors in test_vectors? Do they also yield a different result?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

jmoles commented 3 years ago

I'm having a hard time getting this back up and running. I haven't touched it in a very long time and also don't have access to the tools I used to build this code before. I tried to get it set up running in verilator (put my work in a branch called verilator), but am struggling to get it working One thing to note was the value it looks like you are getting as output from the verilog matches that in the reference out see here. A couple questions:

I'll keep trying to get it up and running. Knowing what simulator tool you are using...I can try to set my setup to match yours.

etam89 commented 3 years ago

result of the run matches the test vectors in the otuput file.

the Keccak Team's VHDL has only keccak-512 test vector. can their VHDL be configured for 215? if so, do you know how?

I used Synopsys VCS for the simulatoin. I guess you can use icarus verilog for that. it's pretty easy to setup.

Thanks!

jmoles commented 3 years ago

Good that the run is matching for you in VCS. I was able to get it running in Verilator. I committed all of the code and also set it up to run with Travis CI to compare the simulations to their results.

As for the VHDL, I have not ran it for several years, so I am not sure it's capabilities. About a month ago, someone submitted a merge request (I accepted and merged it in) to add support for variable width input (see #1). Be curious to see if it works for your needs. Also, feel free to push in a pull request on it. Happy to add anything if it doesn't seem to work correctly.

etam89 commented 3 years ago

the issue seems value of your test vector files doesn't match on-line calculated result. one of such a site is https://emn178.github.io/online-tools/keccak_256.html

jmoles commented 3 years ago

My understanding is that the VHDL (and this Verilog) are a calculation of the intermediate sponge value (not the SHA3 hashing). The test vectors in this repoistory are directly copied from the VHDL implementation. The Keccak team provides both input and output vectors for testing. Since this is just an intermediate sponge calculation, I do not believe most online calculators would not match these values.

Will admit I am mainly translated the Keccak/SHA3 algorithm and do not have a deep understanding of the Keccak internals. I ultimately defer to what the Keccak web site. This code is just a Verilog implementation of their VHDL implementation.

kop316 commented 3 years ago

Hello,

I have been using the code, I can can confirm it confirms to the keccak standards here: https://keccak.team/hardware.html

I was actually going to ask. I have modified the code heavily to decouple the input buffer from the main code, and I was wondering if you would want it. The output buffer no longer matches what you do, but if you are interested I can hand it over.

jmoles commented 3 years ago

@chris4795, definitely interested! When I originally wrote this, I just direct translated the VHDL code from the Keccak team. Think it would be great to share some of the improvements. You up for doing a pull request on it?

kop316 commented 3 years ago

Just did.

I noted major differences in the code (it is not a 1:1 drop in at all....but with a little bit of work it can be).

Let me know if you have any questions about the code!

etam89 commented 3 years ago

Chris,

are you going to update and fix it?

Thanks Eugene

kop316 commented 3 years ago

...Update and fix what?

You may have a misunderstanding of what is happening. The code as is works, as I used it and modified it heavily. The testbench matches what you get at https://keccak.team/hardware.html (this is the reference hardware from the actual keccak team that wrote SHA-3)

I am simply giving back my modifications as-is for Josh to look at, and if he likes them, he (or you) is welcome to work on it to incorporate them. I am not updating anything.

What you are likely observing is that the 64 (or is it 32?) bit input/output buffer is sending out the bits in the opposite order, so it is not matching what you get online. It caught me off guard when I first used it. But since it matches the testbench you get from the reference hardware, it definitely works.

kop316 commented 3 years ago

Looking again, the reason you get a different output is because your input to the websites are wrong: AED66CE184BE232900000010F149905200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000

8000000000000000 should be first, AED66CE184BE23 should be last,

so the right input is: 8000000000000000 ..... AED66CE184BE23

Try that, and if it doesnt match, post what input and output you use.

etam89 commented 3 years ago

Hi Chis,
I have tried the byte order as you mentioned on this website: https://emn178.github.io/online-tools/keccak_256.html input: 8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010F1499052AED66CE184BE2329 output: f049e8b58bf311d0287f0522749815e583bbfbbdf6b889df6b24afbbf8b3f709 not matching verilog result of: 0x9709bcc8...

kop316 commented 3 years ago

I'm not sure why they have incorrect output:

https://keccak.team/files/KeccakVHDL-3.1.zip

In that zip: /3.1/new_test_vector/reccak_ref_out.txt

first entry:

9709BCC8BB23DC25 2B5F3EBB60243373 F778F2E0E8C729A1 852FBE3858D35C2D

In case I have not mentioned it before: https://keccak.team/files/KeccakVHDL-3.1.zip this is literally a hardware implimentation from the creators of keccak. I trust their output over a random website.

etam89 commented 3 years ago

keccak 512 is matching between an opencore keccak and website though.