5 ms·

From your two comments, it's clear you skimmed the text you're trying to discuss here. How can your opinion be regarded as relevant in any way? You highlight th

by fraktl 7y ago

From your two comments, it's clear you skimmed the text you're trying to discuss here. How can your opinion be regarded as relevant in any way? You highlight that author is not familiar with something (he is, he's actually well respected expert who explains everything in fine detail), yet you've shown you don't read carefully at all. I found PASETO's website, rfc and github within.. 3 seconds of using my PC. I'm 100% sure you're capable of doing the same. Your comment looks like unnecessary criticism because you feel provoked since someone criticized a piece of technology you use.

thefounder 7y ago
Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE (i.e only secure alg; no "none" option etc) and at the same time develop a secure by default JOSE library rather than to invent a new protocol, with a new format and new libraries? I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP.
- lvh 7y ago
  PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for example, a myriad of double-spend attacks), but they involve off-label use, which PASETO precludes. By contrast, JWT was clearly not designed to be resilient against insecure implementation. A cryptographic engineer reading the spec would already have snorted milk through their nose at the sight of the "alg" header, the primitives included PKCSv15 RSA as a default _years_ after we knew it was unsafe, et cetera. A strict JOSE might help, but I think it'll be ineffectual. There's little incentive to move ("we already audited this") and there's lots of incentive to stay because compatibility concerns reach further than security ("Cognito does this weird thing with base64 codas that is different from everyone else and we have to support Cognito"). Consider flipping it around as a thought experiment: if you were willing to give up compatibility, and you were going to integrate a new library anyway, why not go whole hog and do a protocol that was always safe?
- fraktl 7y ago
  > Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE It would, I agree 100%. Less options and less standards we have - the better. I support your notion here.
- CiPHPerCoder 7y ago
  > I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP. The specification is here: https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs If you can write an insecure implementation without violating the specification, please file an issue on Github.
  - skrebbel 7y ago
    Here's another thing I like about PASETO: because it's versioned, communicating about insecurities found further down the line is much easier. With JWT you have to say stuff like "ensure that alg can't be 'none' and that your JWT library doesn't accept arbitrary alg fields". This is messy. With PASETO you can just say "be sure to use v3 or later" (assuming someone finds a flaw in v2, files that issue, and that is then addressed in a v3 of the spec). Similarly, implementations can just write "supports versions 1 through 3" on their README.
    - thefounder 7y ago
      Nothing stops you from versioning JOSE. You may start with version 1 right now and consider anything beneath it insecure.
  - thefounder 7y ago
    ok, and what happens if / when a vulnerability is found? You increase the version number? How is that different than a versioned JOSE?
    - CiPHPerCoder 7y ago
      In addition to versioning, we're starting with a very limited set of functionality tuned to security not flexibility. If you're using v2, you're either signing with Ed25519 or encrypting with XChaCha20-Poly1305. There are no additional knobs or levers. Only boring cryptography. A versioned JOSE that limited flexibility is dead in the water. JOSE users will bikeshed over backeards compatibility until the end of time. Might as well specify a new standard at that point. Hence PASETO.

by fraktl 7y ago

thefounder 7y ago

Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE (i.e only secure alg; no "none" option etc) and at the same time develop a secure by default JOSE library rather than to invent a new protocol, with a new format and new libraries? I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP.

lvh 7y ago
PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for example, a myriad of double-spend attacks), but they involve off-label use, which PASETO precludes. By contrast, JWT was clearly not designed to be resilient against insecure implementation. A cryptographic engineer reading the spec would already have snorted milk through their nose at the sight of the "alg" header, the primitives included PKCSv15 RSA as a default _years_ after we knew it was unsafe, et cetera. A strict JOSE might help, but I think it'll be ineffectual. There's little incentive to move ("we already audited this") and there's lots of incentive to stay because compatibility concerns reach further than security ("Cognito does this weird thing with base64 codas that is different from everyone else and we have to support Cognito"). Consider flipping it around as a thought experiment: if you were willing to give up compatibility, and you were going to integrate a new library anyway, why not go whole hog and do a protocol that was always safe?
fraktl 7y ago
> Let me ask you this: wouldn't make more sense to publish a rfc for a more strict JOSE It would, I agree 100%. Less options and less standards we have - the better. I support your notion here.
CiPHPerCoder 7y ago
> I can surely write some bad libraries for PASETO and someone could come up with the same arguments against PASETO like the OP. The specification is here: https://github.com/paragonie/paseto/tree/master/docs https://github.com/paragonie/paseto/tree/master/docs If you can write an insecure implementation without violating the specification, please file an issue on Github.
- skrebbel 7y ago
  Here's another thing I like about PASETO: because it's versioned, communicating about insecurities found further down the line is much easier. With JWT you have to say stuff like "ensure that alg can't be 'none' and that your JWT library doesn't accept arbitrary alg fields". This is messy. With PASETO you can just say "be sure to use v3 or later" (assuming someone finds a flaw in v2, files that issue, and that is then addressed in a v3 of the spec). Similarly, implementations can just write "supports versions 1 through 3" on their README.
  - thefounder 7y ago
    Nothing stops you from versioning JOSE. You may start with version 1 right now and consider anything beneath it insecure.
- thefounder 7y ago
  ok, and what happens if / when a vulnerability is found? You increase the version number? How is that different than a versioned JOSE?
  - CiPHPerCoder 7y ago
    In addition to versioning, we're starting with a very limited set of functionality tuned to security not flexibility. If you're using v2, you're either signing with Ed25519 or encrypting with XChaCha20-Poly1305. There are no additional knobs or levers. Only boring cryptography. A versioned JOSE that limited flexibility is dead in the water. JOSE users will bikeshed over backeards compatibility until the end of time. Might as well specify a new standard at that point. Hence PASETO.