4 ms·

From https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 > * Flaws in crypto protocols aren't exclusive to, but tend to

From https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 > * Flaws in crypto protocols aren't exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and "cipher suite" negotiation towards other mechanisms. Trevor Perrin's Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That's a disqualifying own-goal. My proposal replaces the joinery with "select a version". You don't get to mix-and-match primitives. You won't fall into the trap of Reasoning By Lego. > Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. I'm not throwing my hands up and saying "fend for yourselves". I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time, as keeping a roof over my family's head takes precedence over doing a lot of thankless unpaid work.

deathanatos 9y ago
This is a much better point (or perhaps a much better way of stating it) than what I got from your original post. I agree wholehearted that you don't want to give the end-user mix-and-match primitives. But I don't think that JWT really gives you that, at least at the level I think you're discussing. For example, JWT doesn't let you choose an asymmetric cipher and a hash algorithm; you have to choose a precomposed whole, such as "RS256" (RSA w/ SHA-256) or "HS256" (HMAC w/ SHA-256). To me, this seems equivalent to NaCl, in a sense. In JWT, I must choose one of "RS256", "HS256", etc. In NaCl, I must choose one of the crypto_* functions. Are these not both giving the user equivalent choices between equivalently pre-composed functionality? (Are you simply saying that the JWT standards offer too many choices between essentially equivalent cryptographic combinations, such as multiple choices for HMAC or RSA, and/or that you disagree w/ the exact combinations offered?) > I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time Perhaps it's what you're leaving unsaid, but the gist I get from your proposal is that you're discarding the entirety of JWT's claims section, essentially equating a JWT with an authenticated and potentially encrypted message; i.e., the output of the NaCl functions that you present.

deathanatos 9y ago

This is a much better point (or perhaps a much better way of stating it) than what I got from your original post. I agree wholehearted that you don't want to give the end-user mix-and-match primitives. But I don't think that JWT really gives you that, at least at the level I think you're discussing. For example, JWT doesn't let you choose an asymmetric cipher and a hash algorithm; you have to choose a precomposed whole, such as "RS256" (RSA w/ SHA-256) or "HS256" (HMAC w/ SHA-256). To me, this seems equivalent to NaCl, in a sense. In JWT, I must choose one of "RS256", "HS256", etc. In NaCl, I must choose one of the crypto_* functions. Are these not both giving the user equivalent choices between equivalently pre-composed functionality? (Are you simply saying that the JWT standards offer too many choices between essentially equivalent cryptographic combinations, such as multiple choices for HMAC or RSA, and/or that you disagree w/ the exact combinations offered?) > I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time Perhaps it's what you're leaving unsaid, but the gist I get from your proposal is that you're discarding the entirety of JWT's claims section, essentially equating a JWT with an authenticated and potentially encrypted message; i.e., the output of the NaCl functions that you present.