Initial derived key

[Dan Weinand]

Hello group,

I'm new to macaroons and about to start a project that will use them in production.

I've been looking through the various implementations and I'm confused about the use of 'macaroons-key-generator' as the initial private key to then hash the user-specified key that every implementation seems to be doing.

From this commit, it looks like this originated in libmacaroons with the intention to handle keys that weren't 32 bytes. Since 'macaroons-key-generator' itself has to be zero-padded, my assumption is that the concern was specifically keys greater than 32 bytes.

However, both RFC 2104 and FIPS 198-1 specify that keys longer than the required number of bytes, should first be hashed to produce a key of the correct length.

For instance, this is what golang's crypto/hmac package, OpenSSL, and libsodium all do.

Am I missing some other reason for the initial derived key?

-- 

Dan Weinand

[Robert Escriva]

Personally I prefer to skip the part that derives a key and uses raw bytes. This requires keeping a private way to map an identifier to the root secret for each macaroon. I believe I added the key derivation to libmacaroons because people convinced me (rightly so, probably) that people generally couldn’t be trusted to use a sufficiently good secret because the README was using human readable keys purely for exposition (and that set a bad example).

Sent from mobile; please excuse my brevity 

--
You received this message because you are subscribed to the Google Groups "Macaroons" group.
To unsubscribe from this group and stop receiving emails from it, send an email to macaroons+...@googlegroups.com.
To post to this group, send email to maca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaroons/a8a2991c-bc90-407c-98b3-7cab9bd88d37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Weinand]

Maybe I’m missing something,  but I don’t see how HMACing a bad key with another short we’ll known key adds any real security benefit.

That’s interesting that you are bypassing that step as other implementations don’t always make that possible and generally seem to be treating the derived key as an implicit requirement for compatibility.

I’m not sure what existing production implementations are depending on the derived key, but it strikes me as something that would be best to move away from.

On the concern of using adequate keys, there are other options:

1) Fail on keys that are shorter than the required length instead of padding them. (This deviates from the aforementioned RFC, but in a way that makes things more secure). Ideally, you’d want this requirement to be documented and standardized so that other implementations don’t pass off a macaroon that can only be validated with an invalid key.

2) Use more realistic examples in documentation, including possibly the libsodium functions that can generate a secure key for you.

I’m currently working on a new implementation, which is where all of this is coming from. My current plan is not to include the derived key methodology in the core macaroon generation logic and instead have a separate derived key function users can use to prepare their keys if needed for compatibility.

-- 

Dan Weinand

To view this discussion on the web visit https://groups.google.com/d/msgid/macaroons/A22A42BC-ADDA-4C80-B6C9-000BD7E96FA5%40rescrv.net.