add more compact encoding

[funny-falcon]

Current encoding does Base64 twice against payload because of intermediate
text encoding. And it produces too large mac (256bit) while 128bit is more
than enough.

Add "compact" mode which uses binary encoding for message with single
Base64 pass and 128bit hmac output (at max).

    TestSecureCookie: securecookie_test.go:48: i 0 len 184                                                         
    TestSecureCookie: securecookie_test.go:48: i 1 len 128                                                         
    TestSecureCookie: securecookie_test.go:48: i 2 len 188                                                         
    TestSecureCookie: securecookie_test.go:48: i 3 len 128                                                         
    TestSecureCookie: securecookie_test.go:48: i 4 len 188                                                         
    TestSecureCookie: securecookie_test.go:48: i 5 len 128                                                         
    TestSecureCookie: securecookie_test.go:48: i 6 len 188                                                         
    TestSecureCookie: securecookie_test.go:48: i 7 len 128                                                         
    TestSecureCookie: securecookie_test.go:48: i 8 len 188                                                         
    TestSecureCookie: securecookie_test.go:48: i 9 len 128                                                         

[elithrar]

Note that any encoding change has the effect of breaking all existing sessions, as they are no longer compatible.

…

On Sun, Jun 28, 2020 at 8:50 PM Sokolov Yura ***@***.***> wrote: Current encoding does Base64 twice against payload because of intermediate text encoding. And it produces too large mac (256bit) while 128bit is more than enough. Add "compact" mode which uses binary encoding for message with single Base64 pass and 128bit hmac output (at max). TestSecureCookie: securecookie_test.go:48: i 0 len 184 TestSecureCookie: securecookie_test.go:48: i 1 len 128 TestSecureCookie: securecookie_test.go:48: i 2 len 188 TestSecureCookie: securecookie_test.go:48: i 3 len 128 TestSecureCookie: securecookie_test.go:48: i 4 len 188 TestSecureCookie: securecookie_test.go:48: i 5 len 128 TestSecureCookie: securecookie_test.go:48: i 6 len 188 TestSecureCookie: securecookie_test.go:48: i 7 len 128 TestSecureCookie: securecookie_test.go:48: i 8 len 188 TestSecureCookie: securecookie_test.go:48: i 9 len 128 ------------------------------ You can view, comment on, or merge this pull request online at: #72 Commit Summary - add more compact encoding File Changes - *M* securecookie.go <https://github.com/gorilla/securecookie/pull/72/files#diff-c51d3fc36978add43da88584bf60eca6> (120) - *M* securecookie_test.go <https://github.com/gorilla/securecookie/pull/72/files#diff-b1d1c2d21c81de3e631840c495417e79> (13) Patch Links: - https://github.com/gorilla/securecookie/pull/72.patch - https://github.com/gorilla/securecookie/pull/72.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#72>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQ4DOSIJ7C4CTLW4S4ADRZAFPRANCNFSM4OK3XQJA> .

[funny-falcon]

@elithrar that is why current encoding is preserved and remains to be default.
To migrane smoothly one will have to create couple of SecureCookie, enable Compact(true) on one and use `DecodeMulti

[funny-falcon]

Probably it will be better to move timestamp backward: currently compact encoded cookie always starts with AAAAA .
Other option could be to use binary.PutVarint.

[funny-falcon]

Yeah, changed it to varint, and it doesn't even look weird.

[funny-falcon]

So, will there be consensus about this feature? Close it or merge it?

[funny-falcon]

Hmm, looks like there is a way to be backward compatible: if I place 0 byte first (before base64 encoding), then there is clear way to distinguish between compact encoding and text based encoding.

I also made such trick to avoid nonce in private repository:
I used mac as nonce for encryption.

mac = Blake2b(14, nil).Sum(version||(namelen,keylen)||name||hashkey||timeMilliSec||message)) // mac is 14 bytes 
cipherText = (timeMilliSec||message) ^ ChaCha20(combine(blockKey,mac[12:14]), mac[:12])
cookie = version||mac||cipherText

where

version - zero byte
timeMilliSec - LittleEndian.PutUint64(time.Now().UnixNano() >> 20) . It plays role of semi-nonce as mac is used for encryption.
(namelen,keylen) - two bytes. I limit name len with 127 bytes to be able in future use varint encoding.
mac is 14 bytes cause I think 112 bits is just enough. Since version bytes goes first, it will be possible to increase it in a future.
hashkey is prepared as Blake2b256(userHashKey)
blockKey is prepared as Blake2b256(userBlockKey, hashKey) (therefore is it 32 bytes, as it is needed for ChaCha20)
combine(blockKey, mac[12:14]) - xors last two blockKey bytes with last two bytes of mac, therefore whole 112bit of mac is used for encryption.

I'd like to change this PR this way if you don't mind.

[funny-falcon]

comparison of such scheme with current secure cookie using NopEncoder on messages 0-250bytes long:

BenchmarkCompactEncode    914350              1310 ns/op             717 B/op          4 allocs/op
BenchmarkCompactEncode    932637              1315 ns/op             717 B/op          4 allocs/op
BenchmarkSecureEncode     244792              4889 ns/op            3443 B/op         21 allocs/op
BenchmarkSecureEncode     223064              4840 ns/op            3443 B/op         21 allocs/op
BenchmarkCompactDecode    920700              1322 ns/op             494 B/op          4 allocs/op
BenchmarkCompactDecode    920559              1324 ns/op             494 B/op          4 allocs/op
BenchmarkSecureDecode     289554              4057 ns/op            2391 B/op         17 allocs/op
BenchmarkSecureDecode     290959              4062 ns/op            2391 B/op         17 allocs/op

[funny-falcon]

close in favor of #73