TestSessionKeyString fails with Go 1.18beta1

[alexsaezm]

TestSessionKeyString fails with Go 1.18beta1. The tests works perfectly fine with 1.16 and 1.17.

$ go test -timeout 30s -run ^TestSessionKeyString$ github.com/schollz/pake/v3

A) K=2aa81297fa72950b1bef3e6b5000e8ccdd9c6d348b5a844974ed6ce74e75ab03
B) K=5bf61df897ea1e8c8a489af28d7f62c0935764b5db240fa1d0c91d5470fe5001
A) K=4902c62d68faa54d8f4292204fd4eeee26bfc0a220827a16c867b7a07eb0c683
B) K=4902c62d68faa54d8f4292204fd4eeee26bfc0a220827a16c867b7a07eb0c683
A) K=5300161ccb0bdb88a47288e795fa00fc4da37ef2e5570dbb78da00567b03855b
B) K=5f2e1ddb906239e06f84bd89e3a8851e0539c290302c023f5a85849e30ab463e
A) K=6bb4da6b112c07c6bf3ab1db2cc4431ae244b49952591e16ae0f9e5c370d52e5
B) K=6bb4da6b112c07c6bf3ab1db2cc4431ae244b49952591e16ae0f9e5c370d52e5
--- FAIL: TestSessionKeyString (0.06s)
    /home/alex/Developer/src/github.com/schollz/pake/pake_test.go:68: 
            Error Trace:    pake_test.go:68
            Error:          Not equal: 
                            expected: []byte{0x2a, 0xa8, 0x12, 0x97, 0xfa, 0x72, 0x95, 0xb, 0x1b, 0xef, 0x3e, 0x6b, 0x50, 0x0, 0xe8, 0xcc, 0xdd, 0x9c, 0x6d, 0x34, 0x8b, 0x5a, 0x84, 0x49, 0x74, 0xed, 0x6c, 0xe7, 0x4e, 0x75, 0xab, 0x3}
                            actual  : []byte{0x5b, 0xf6, 0x1d, 0xf8, 0x97, 0xea, 0x1e, 0x8c, 0x8a, 0x48, 0x9a, 0xf2, 0x8d, 0x7f, 0x62, 0xc0, 0x93, 0x57, 0x64, 0xb5, 0xdb, 0x24, 0xf, 0xa1, 0xd0, 0xc9, 0x1d, 0x54, 0x70, 0xfe, 0x50, 0x1}

                            Diff:
                            --- Expected
                            +++ Actual
                            @@ -1,4 +1,4 @@
                             ([]uint8) (len=32) {
                            - 00000000  2a a8 12 97 fa 72 95 0b  1b ef 3e 6b 50 00 e8 cc  |*....r....>kP...|
                            - 00000010  dd 9c 6d 34 8b 5a 84 49  74 ed 6c e7 4e 75 ab 03  |..m4.Z.It.l.Nu..|
                            + 00000000  5b f6 1d f8 97 ea 1e 8c  8a 48 9a f2 8d 7f 62 c0  |[........H....b.|
                            + 00000010  93 57 64 b5 db 24 0f a1  d0 c9 1d 54 70 fe 50 01  |.Wd..$.....Tp.P.|
                             }
            Test:           TestSessionKeyString
    /home/alex/Developer/src/github.com/schollz/pake/pake_test.go:68: 
            Error Trace:    pake_test.go:68
            Error:          Not equal: 
                            expected: []byte{0x53, 0x0, 0x16, 0x1c, 0xcb, 0xb, 0xdb, 0x88, 0xa4, 0x72, 0x88, 0xe7, 0x95, 0xfa, 0x0, 0xfc, 0x4d, 0xa3, 0x7e, 0xf2, 0xe5, 0x57, 0xd, 0xbb, 0x78, 0xda, 0x0, 0x56, 0x7b, 0x3, 0x85, 0x5b}
                            actual  : []byte{0x5f, 0x2e, 0x1d, 0xdb, 0x90, 0x62, 0x39, 0xe0, 0x6f, 0x84, 0xbd, 0x89, 0xe3, 0xa8, 0x85, 0x1e, 0x5, 0x39, 0xc2, 0x90, 0x30, 0x2c, 0x2, 0x3f, 0x5a, 0x85, 0x84, 0x9e, 0x30, 0xab, 0x46, 0x3e}

                            Diff:
                            --- Expected
                            +++ Actual
                            @@ -1,4 +1,4 @@
                             ([]uint8) (len=32) {
                            - 00000000  53 00 16 1c cb 0b db 88  a4 72 88 e7 95 fa 00 fc  |S........r......|
                            - 00000010  4d a3 7e f2 e5 57 0d bb  78 da 00 56 7b 03 85 5b  |M.~..W..x..V{..[|
                            + 00000000  5f 2e 1d db 90 62 39 e0  6f 84 bd 89 e3 a8 85 1e  |_....b9.o.......|
                            + 00000010  05 39 c2 90 30 2c 02 3f  5a 85 84 9e 30 ab 46 3e  |.9..0,.?Z...0.F>|
                             }
            Test:           TestSessionKeyString
FAIL
FAIL    github.com/schollz/pake/v3  0.059s
FAIL

This issue appeared in a Fedora package review, but it is not related with the package system.

[szpak]

I would be nice to see croc in Fedora. As I understood, this issue complicates the thing as pake is needed to be packaged before croc. @schollz I wonder, if it is just a problem with tests or with 1.18 pake could do not function correctly?

[schollz]

Thanks for bringing this up @alexsaezm. It seems that Go1.18 now assumes that the point on the curve has been modulo-ed against the order of the underlying field. Will wait to see how this is addressed before addressing here.