tuupola / branca-spec Goto Github PK

Go implementation is missing. Something similar as fernet-go by @kr. Anyone interested in implementing it write me a note here and I will add it to the docs.

The known implementations in the readme are links to libsodium implementations, not branca ones.

https://github.com/tuupola/branca-spec/blob/b1ecd47ae7eb27b86f50cb72b47ab90b1f5b3bfd/README.md#libraries

General feedback welcome here. Ie. Am I doing something wrong?

DotNet implementation is missing. Could use xchacha-dotnet by @tom-auger as basis.

Note that this is Authenticated Encryption with Additional Data (AEAD) where the he header part of the token is the additional data.

The word ‘he’ should be removed.

Looks like DNS isn't set up.

The README refers to a non-existing License file. This should probably be added.

If I understood the Branca specs correctly, the timestamp field seems to be unprotected.

Let's say a website uses Branca tokens as session cookies and relies on the timestamp field in order to check if the token is still valid. An attacker might get access to a valid or expired token and manipulate the timestamp field whenever needed in order to make the expired token valid again.
This applies not only to the context of websites and session cookies but to every possibly untrusted environment in which Branca tokens could be used.

As far as I can tell, the timestamp field doesn't provide any reliable information in an untrusted environment.

I'm writing this because not everyone using Branca tokens might be aware of that. I suggest to either make this very clear in the documentation or to change the spec so that tampering with the timestamp field can be detected.

Clojure implementation would be great. Something similar as fernet-clj by @derwolfe.

Hi! We have been released our high-grade quality package with Branca implementation - https://github.com/essentialkaos/branca

Features:

• Pure Go implementation;
• No third-party dependencies at all;
• 100% code coverage;
• Fuzz tests.

I think it will be great to add information about this package to the branca website.

The branca.io website, linked in the about section of GitHub repositories and readme’s is down.

See https://twitter.com/CiPHPerCoder/status/889145777687232514

The character set provided in the spec:

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxy

Only contains 61 characters, and is thus a base61 encoding. Looking at the implementations listed on the document, it seems that most of them (if not all) include a z to the character set as I would expect.

Is this the intended behaviour? Or should the character set not include the character z?

Swift implementation is missing. Something similar as fswift-jwt by @stannie.

I think it would make sense to specifically state, that the expiration check for a token using a ttl should happen after authenticating and decrypting. If it happens before, a user would never know if an expired token they received was tampered into expiring, or actually did expire.

Python implementation is badly needed. Something similar as pyjwt by @jpadilla. Anyone interested in implementing it write me a note here and I will add it to the docs.

Laravel and Lumen support would be awesome. Something similar as jwt-auth by @tymondesigns. You could also check branca-middleware for inspiration. PHP library for encoding and decoding tokens already exists.

Anyone interested in implementing it write me a note here and I will add it to the docs.

Dart implementation is missing. Could use firstfloorsoftware/flutter_sodium by @firstfloorsoftware.

$size = CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES;
$random = random_bytes($size);
$nonce = sodium_crypto_generichash($payload, $random, $size);

I think it would be good to concretize this a bit to make it clearer, by specifically stating the algorithm this example uses (BLAKE2b IIRC). Also, what if sodium_crypto_generichash changes at some point? If we specifically state the algorithm tied to hashing for the nonce, we can tie that to the version and change it in the far future if need be. The last part is not too important, I'm more into specifying it to make it clear what algorithm is considered secure. In case a user might try to use something else, if libsodium is not accessible to them.

Is timestamp a security risk? Ie. should there be another version without timestamp in header?Currently it is possible to opt out by passing a 0 or false as timestamp. This still wastes a few bytes per request.

Current feeling is making another version just to save 4 bytes is not worth the hassle.

The Javascript reference implementation has recently changed to enforce the use of more secure 32 byte hex keys, or a 32 byte Buffer. This change is to require the use of cryptographic keys of the proper length and construction as expected by the underlying encryption algorithm.

https://github.com/tuupola/branca-js

The spec should be modified to:

• add additional context to the spec README about why this change was made
• note that it is likely a breaking change and thus might require version bumping the spec
• modify the test vectors so they will work with the new key mechanism

Other downstream implementations should also be encouraged to adopt the new spec to maintain cross library interoperability.

Rust implementation would be welcome. Something similar as frank_jwt by @GildedHonour. Anyone interested in implementing it write me a note here and I will add it to the docs.

In the “What is Branca” opening section the word encrypted is spelled incorrectly as ‘ enrypted ’.

Hello @tuupola ,

I discovered Branca a while ago and I like the spec. I have done a Crystal implementation for it: Branca.cr
It makes use of Monocypher with bindings from monocypher.cr.

You may take a look at it.

Kind regards
Johannes

Erlang implementation is missing. Something similar as fernet-erl by @bigkevmcd. Anyone interested in implementing it write me a note here and I will add it to the docs.

Should specify that used Base62 encoding is byte by byte.

Ruby implementation is missing. Something similar as fernet-rb by @hgmnz. Anyone interested in implementing it write me a note here and I will add it to the docs.