Skip to content
New issue

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

x/crypto: argon2id hash mismatch with reference implementation #31507

Closed
KawaiDesu opened this issue Apr 17, 2019 · 3 comments
Closed

x/crypto: argon2id hash mismatch with reference implementation #31507

KawaiDesu opened this issue Apr 17, 2019 · 3 comments
Milestone

Comments

@KawaiDesu
Copy link

@KawaiDesu KawaiDesu commented Apr 17, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.4 linux/amd64

Does this issue reproduce with the latest release?

I'm already using latest.

What operating system and processor architecture are you using (go env)?

Archlinux from 16.04.2019
CPU:

lscpu output
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       39 bits physical, 48 bits virtual
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               142
Model name:          Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
Stepping:            10
CPU MHz:             800.009
CPU max MHz:         4000.0000
CPU min MHz:         400.0000
BogoMIPS:            3985.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            8192K
NUMA node0 CPU(s):   0-7
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/zmey/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/zmey/.gopath"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build851107517=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I was using argon2 library (golang.org/x/crypto/argon2) and decid thed to check reproducibility of hash result with reference implemetation, which can be found at https://github.com/P-H-C/phc-winner-argon2 (https://godoc.org/golang.org/x/crypto/argon2 has a reference to it).

What did you expect to see?

Executing argon2() with same parameters for x/crypto lib and ref version I would expect at least same hash result and ideally similar execution time.

What did you see instead?

Instead i'v got totally irrelevant results. I'v written program and script for testing:

package main

import (
    "fmt"
    "golang.org/x/crypto/argon2"
    "time"
)

func main() {
    for iters := 2; iters <= 70000; iters *= 2 {
        tStart := time.Now()
        dkey := argon2.IDKey([]byte("SomeKey16CharLen"), []byte("somesalt"), uint32(iters), 2^16, 1, 8)
        tEnd := time.Now()
        fmt.Printf("iters: %d\tresult: %x\ttime: %v\n", iters, dkey, tEnd.Sub(tStart))
    }
}
#!/bin/bash

for ITERS in 2 4 8 16 32 64 128 256 512; do
	RESULT="$((time eval 'echo -n "SomeKey16CharLen" | phc/argon2 somesalt -id -t ${ITERS} -m 16 -p 1 -l 8') 2>&1)"
	HASH="$(grep Hash <<< "$RESULT" | awk '{print $2}')"
	TIME="$(grep real <<< "$RESULT" | awk '{print $2}')"
	echo -e "iters: ${ITERS}\tresult: ${HASH}\ttime: ${TIME}"
done

Here is results.
x/crypto/argon2:

iters: 2	result: 1a16f5cf58fb06fd	time: 139.74µs
iters: 4	result: e399b76071673961	time: 148.875µs
iters: 8	result: 2556103bad749067	time: 244.746µs
iters: 16	result: 9d2996926dabcf35	time: 439.948µs
iters: 32	result: d42584fbf7303d72	time: 914.983µs
iters: 64	result: e12ae1f5e7f6a6d2	time: 1.792167ms
iters: 128	result: 9d3505856901773f	time: 3.435604ms
iters: 256	result: 4029f33fc2b33910	time: 6.883196ms
iters: 512	result: aa6732b30a0bef04	time: 14.113788ms
iters: 1024	result: 04618924fc9a7dbf	time: 25.822188ms
iters: 2048	result: 662aa679f8737cb9	time: 47.643061ms
iters: 4096	result: cb5634a3bad2f2f2	time: 93.270525ms
iters: 8192	result: 021547747e42a912	time: 178.898982ms
iters: 16384	result: b4bdc42c8340cff5	time: 348.955178ms
iters: 32768	result: 6a053e39123c7f79	time: 683.547191ms
iters: 65536	result: 2f664e3585ebe007	time: 1.356076541s

reference binary:

iters: 2	result: 4d3ce6425c81d309	time: 0m0.193s
iters: 4	result: 7ba2b8fc42ca755d	time: 0m0.310s
iters: 8	result: de25c04e0123aba5	time: 0m0.562s
iters: 16	result: d017f15189665f13	time: 0m1.068s
iters: 32	result: 13bd536d9f5e017a	time: 0m2.048s
iters: 64	result: 5696809b6c932ce2	time: 0m3.972s
iters: 128	result: 557fd8e526c5ac81	time: 0m7.824s
iters: 256	result: 25bde0bff7f73888	time: 0m15.583s
iters: 512	result: 30585dbb577a2d31	time: 0m31.017s

So, am i dumb somewhere or it's just a bug in one of implementations?

@gopherbot gopherbot added this to the Unreleased milestone Apr 17, 2019
@tonyb486
Copy link

@tonyb486 tonyb486 commented Apr 17, 2019

You used 2^16 instead of 65536 for your test code for the memory usage . The ^ operator here is actually a bitwise xor, not an exponent. With 65536 there it matches the reference binary. :)

@KawaiDesu
Copy link
Author

@KawaiDesu KawaiDesu commented Apr 17, 2019

I feel so stupid right now... 😞
Thanks a lot!

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Apr 17, 2019

I have made the same mistake at least thrice :)

@golang golang locked and limited conversation to collaborators Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.