brejoc/gosgp

Hashing not corresponding with SGP-hashing anymore

Closed this issue · 7 comments

I've just noticed, that the generated hash is not compliant with the original SGP-hash since commit
89b7352.

For the domain 'foo.com' with the master password '12345' the output looks like this.
SGP: iPCLNbu4Zq
gosgp: uMTGXp3Frk

Was that on purpose?

@mgumz Sorry, forgot to mention you.

on which platform? because i use d77b26c and it looks like this:

% uname -a
Darwin mymachine.trusted 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
% git rev-parse HEAD
d77b26c
% go version
go version go1.4 darwin/amd64
% go clean -v
% go build -v
github.com/mgumz/gosgp
% ./gosgp -domain="foo.com"
password:
iPCLNbu4Zq

i added the sample to sgp_test.go (to avoid mistyping etc) and this is the output:

=== RUN TestSupergenPassMd5
--- PASS: TestSupergenPassMd5 (0.00s)
sgp_test.go:49: 0 supergenpass("1","example.com") = "dlHhFkN3vr"
sgp_test.go:49: 1 supergenpass("123","example.com") = "mhn91FJ7Ug"
sgp_test.go:49: 2 supergenpass("mypassword123","github.io") = "cCB9oTktwn"
sgp_test.go:49: 3 supergenpass("12345","foo.com") = "iPCLNbu4Zq"

I've noticed this on Ubuntu 14.04 amd64.

$ uname -a
Linux crusher 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ git rev-parse HEAD
d77b26c

$ go version
go version go1.3 linux/amd64

$ go clean -v
$ go build -v
$ ./gosgp -domain="foo.com"
password:
uMTGXp3Frk

The test outputs this:
--- FAIL: TestSupergenPassMd5 (0.00 seconds)
sgp_test.go:48: 0 supergenpass("1","example.com") = "lp4k5HMM7B"
sgp_test.go:54: sample 0: expected "dlHhFkN3vr" (domain: "example.com", pw: "1"), got "lp4k5HMM7B"
--- FAIL: TestSupergenPassSha512 (0.00 seconds)
sgp_test.go:73: 0 supergenpass("1","example.com") = "f852JeJv9z"
sgp_test.go:79: sample 0: expected "o1en6AyDm3" (domain: "example.com", pw: "1"), got "f852JeJv9z"
FAIL
exit status 1
FAIL _/tmp/gosgp 0.003s

seems to be related to go-1.3.x: i can't reproduce the bug with 1.4, i can with 1.3.3 on debian.

yes, it's the way base64.Encode() is implemented: in go 1.4 local variables are used to calculate the resulting values which are then transfered into the destination. in 1.3.x the destination is used directly.

Fixed with commit af4eb16 (see issue #5) from @mgumz.