1. What Is Go-Alone?
2. What Is The Expected Use Case For Go-Alone?
3. How Secure Is Go-Alone?
4. How Performant Is Go-Alone?

## What Is Go-Alone?

Go-Alone is a Go package that provides A very simple to use MAC signer and unsigner that tries to be fairly performant. This is useful for one-time email tokens, authentication tokens, or to cryptographically sign any arbitrary data so that it can be transmitted or stored in an unsecure way but is tamper proof so when it comes back to you, you can verify that it is exactly the same data that you originally signed.

The development of Go-Alone was highly influenced by the popular itsdangerous python library. The tokens Go-Alone creates are very similar to itsdangerous tokens however they are not compatible with each other. Go-Alone uses a faster and more secure BLAKE2b cryptographic hash and an integer optimized base58 coding for timestamps. Also, Go-Alone does not have the "Salt" or serializer features of itsdangerous, however both of those things can still be accomplished. You can prepend your "Salt" key to the secret (this is how salting is done in itsdangerous) and use any of the existing Go serializers before passing the data to Go-Alone for signing.

Go-Alone tokens solve a similar problem to what JSON Web Tokens solve. However Go-Alone tokens are smaller and less complex. This provides an overall more performant solution. The smaller tokens also make them less unwieldy when used in e-mail tokens or URLs.

## What Is The Expected Use Case for Go-Alone?

While Go-Alone can be used to sign any data the expected use case, and the case that the library will be tailored for, is Token Based Authentication of APIs and services wrote in Google Go. If you're new to the concept of Token Based Authentication then I recommend a bit of reading to help get you familiar with it.

## How Secure is Go-Alone?

The security aspect of Go-Alone is based on a keyed BLAKE2b-256 cryptographic hash function. The entire message payload and timestamp (if included) is hashed with a secret key (provided by you) and any change, no matter how small or large, would be detected when verifying the hash. Without the secret key there is no known way to forge a token that Go-Alone would verify without error. So, you should be able to feel confident that if Go-Alone successfully unsigns a token without error then it was originally created using the same secret key and no part of the token was modified. BLAKE2b is said to be at least as secure as the latest standard SHA-3 hash which is much more secure than both HMAC-MD5 and HMAC-SHA1. You can read more about BLAKE2 on it's website here

## How Performant is Go-Alone?

When using Go-Alone for a REST API you have to unsign the Authentication Token provided by the client on every single request to make sure it's valid and has not been tampered with. This adds an overhead to all of your traffic and because of that when developing Go-Alone I attempted to find the most performant ways to accomplish each task without sacrificing security. However, Go-Alone is a pretty small library so there wasn't a whole lot to optimize. There's mainly 3 different aspect of Go-Alone that help make it as fast as possible.

• Cryptographic Hash: There's a lot of cryptographic hash functions that can be used for this task. Not long ago HMAC-MD5 was popular, then HMAC-SHA1 become the standard. Now HMAC-SHA3 is becoming a more recommended standard. The BLAKE2b hash that Go-Alone uses is faster than all of those options. This is stated on the BLAKE2 website but I was able to confirm it by testing each option when creating Go-Alone. Compared to HMAC-SHA3-256 which is an arguably fairly equal security level, BLAKE2b-256 was substantially faster.

• Timestamp Coding:. By using an integer optimized base58 timestamp encoding function Go-Alone is able to both create a fairly small URL friendly representation of the time but also encode and decode the timestamp very quickly. This method is much faster than just encoding using normal base64.

• Token Size: Using the itsdangerous style tokens over something like JWT helps keep the size of each token as small as possible. This is a minor point but it does mean the impact of transferring and storing the token is minimized.