Custom Fernet implementation

[faragher]

I have conceptual questions regarding Reticulum's use of modified Fernet.

For those who aren't familiar, Reticulum uses a modified Fernet implementation. The stock implementation is a base64url encoded token consisting of:

• a one byte version code
• an eight byte timestamp
• a 16 byte AES-128 IV
• a number of 16 byte data blocks
• a 32 byte HMAC

The Reticulum implementation omits the version code and timestamp resulting in an overhead of 48 bytes per token as opposed to 57 bytes per token.

The intent of the timestamp is to de-authenticate a token after a certain period. I can see the thought process of removing data from an unused feature, but it's still part of the specification.

So, I have some concerns. Mostly, this isn't a Fernet implementation. If a Reticulum application developer tries to use the functions with stock Fernet tokens, it will fail (this is by design since HMACs will differ between the two token types) and if someone decides to use a Fernet library, it will fail to connect to Reticulum reference implementations.

I'm not certain if nine bytes is worth the change, but it's done. Any change would break compatibility with every other Reticulum version. I would, however, suggest that beyond even making a note, that the implementation's name is changed. I doubt the name of the token makes any real difference, but a modified implementation with a standard name implies interoperability where none exists.

Should we consider making a change in the terminology or documentation to explicitly remove any expectations of interoperability?

[markqvist]

You are right, keeping the name is misleading. Originally (and long ago), Reticulum used unmodified Fernet.

This was changed since the overhead reduction is very much worth it. The deauthentication is redundant and unnecessary in Reticulum, and saving the 9 bytes has a cascading effect due to block sizes vs packet MTUs, that really does improve efficiency over low-bandwidth mediums.

But yes, we should probably drop the Fernet naming, and come up with something better to describe it. Any ideas?

[faragher]

I have neither done the math nor had the experience. If you tell me it's worth it, then it is.

I've been trying to think of clever names (RINF: RINF is not Fernet, FBT: Fernet, but Timeless, some wine name to riff on Fernet) and very practical names (Reticulum Token or Reticulum Authentication Token, which becomes RAT) but what I've really come up with is I am not entirely certain what to call it, as part of a cryptographic solution.

I guess the big question is "do we think this will be something to be used outside of Reticulum?" If not, I'd just go with the Reticulum Authentication Token, but that doesn't leave something concise for code use. RAT or Token seem like poor choices, and anything longer may get messy.

RToken would mimic the RNode nomenclature. Short, descriptive, and really only programmers would even mention/see it.

[markqvist]

Haha, I'm not sure whether I love or hate RAT ;) I think the likelyhood of this being used outside of Reticulum is pretty small. The current implementation is very much optimised for use within the packet structure and overall scheme of Reticulum. Maybe something completely generic like Simple Authentication Token will fit the bill, and still provide a usable name/label to talk about it (which is more or less the primary purpose, I guess). RToken, Reticulum Token or RT is fine with me too. Not sure what make most sense.

[faragher]

That's the best kind of acronym! Love it or hate it, you won't forget it. :D

I'm going to continue working with the current nomenclature and switch over when/if the main branch does. As an aside, I think HKDF is the last step in getting a first pass on the crypto API being . . . there. The self-tests all work and they've all passed external tests, but I won't know until I can talk to a Python node. Still, Bouncy Castle is notoriously poorly documented, so I'm happy to be moving on to lots of general work instead of a slice of painful work.