4 ms·

> the option to have 'alg: none' should never be used I doubt anyone uses this deliberately (edit: except maybe for internal server to server communications?).

> the option to have 'alg: none' should never be used I doubt anyone uses this deliberately (edit: except maybe for internal server to server communications?). I agree that having it as an option is a footgun. I still think this is a non-issue on the client/backend, most libraries explicitly make you whitelist token signing algorithms and will throw errors if the token isn't signed with the right algorithm. > Even giving the user a choice of ciphers to use is a recipe for disaster. How so? I'm still learning this stuff, so I'm genuinely curious.

CiPHPerCoder 6y ago
> > Even giving the user a choice of ciphers to use is a recipe for disaster. > How so? I'm still learning this stuff, so I'm genuinely curious. https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols https://paragonie.com/blog/2019/10/against-agility-in-crypto... :)
- user5994461 6y ago
  I really hope you're planning some agility in PASETO otherwise it's de-facto s* protocol that will have to be thrown away within a few years upon the first cryptographic weakness, breaking all applications that dared to adopt it. Fact is, ciphers and protocols evolve over time. In the real world of client-servers (often many clients and many servers), it's not possible to magically upgrade all systems at once to exclusively accept a single same cipher. There's got to be a way to phase-in ciphers gradually across systems and phase-off. Agility is simply a real world constraint to be able to operate software in the real world.
  - griffinmb 6y ago
    It’s versioned, which is an improvement on “agility”
  - CiPHPerCoder 6y ago
    > I really hope you're planning some agility in PASETO otherwise it's de-facto s* protocol that will have to be thrown away within a few years upon the first cryptographic weakness, breaking all applications that dared to adopt it. Instead of cipher agility, PASETO uses versioned protocols. My DEFCON Crypto & Privacy Village talk (slides and YouTube video at https://paseto.io https://paseto.io for the curious) covered this distinction in detail.
rvz 6y ago
> How so? I'm still learning this stuff, so I'm genuinely curious. It is the same reason why the author of Wireguard rejected cryptographic agility in its use of protocols and ciphers: From the Wireguard paper [0]: > 'Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.' [0] https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
user5994461 6y ago
Protocols agility allow applications to pick between multiple settings, let's say RSA128 and RSA256 for example. This allows to add and remove ciphers over time, which is very important. In theory it's a bad idea, because it means stuff might select obsolete ciphers during operation, which is bad. In practice, there is no choice but to design agility. Ciphers will invariably get weak after some years (computer get faster) so they need to be phased off and replaced by newer ones. In the real world, there are meshes of client-server interacting with one another. You can't just upgrade the software on one side to only use the newer cipher, or nothing could connect to it anymore. Thus there has to be the capability to work with multiple ciphers, so older ciphers can gradually be phased-in across systems and older cipher phased-off. Pretty sure the two other commenters are mostly researchers with no real world software deployment to manage. Otherwise they wouldn't be so strong against agility. Fact is a system with no agility is dead in the water because it can't evolve.
- masklinn 6y ago
  This is exactly backwards. In theory cipher agility is useful so you can upgrade your suite over time, in practice it’s a terrible idea because it will, and has time and again, lead to downgrade attacks. Crypto researchers have learned this fact of life the hard way, crypto systems are becoming less “agile” over time because this agility means it’s preemptively broken.

CiPHPerCoder 6y ago

> > Even giving the user a choice of ciphers to use is a recipe for disaster. > How so? I'm still learning this stuff, so I'm genuinely curious. https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols https://paragonie.com/blog/2019/10/against-agility-in-crypto... :)

user5994461 6y ago
I really hope you're planning some agility in PASETO otherwise it's de-facto s* protocol that will have to be thrown away within a few years upon the first cryptographic weakness, breaking all applications that dared to adopt it. Fact is, ciphers and protocols evolve over time. In the real world of client-servers (often many clients and many servers), it's not possible to magically upgrade all systems at once to exclusively accept a single same cipher. There's got to be a way to phase-in ciphers gradually across systems and phase-off. Agility is simply a real world constraint to be able to operate software in the real world.
- griffinmb 6y ago
  It’s versioned, which is an improvement on “agility”
- CiPHPerCoder 6y ago
  > I really hope you're planning some agility in PASETO otherwise it's de-facto s* protocol that will have to be thrown away within a few years upon the first cryptographic weakness, breaking all applications that dared to adopt it. Instead of cipher agility, PASETO uses versioned protocols. My DEFCON Crypto & Privacy Village talk (slides and YouTube video at https://paseto.io https://paseto.io for the curious) covered this distinction in detail.

rvz 6y ago

> How so? I'm still learning this stuff, so I'm genuinely curious. It is the same reason why the author of Wireguard rejected cryptographic agility in its use of protocols and ciphers: From the Wireguard paper [0]: > 'Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.' [0] https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf

user5994461 6y ago

Protocols agility allow applications to pick between multiple settings, let's say RSA128 and RSA256 for example. This allows to add and remove ciphers over time, which is very important. In theory it's a bad idea, because it means stuff might select obsolete ciphers during operation, which is bad. In practice, there is no choice but to design agility. Ciphers will invariably get weak after some years (computer get faster) so they need to be phased off and replaced by newer ones. In the real world, there are meshes of client-server interacting with one another. You can't just upgrade the software on one side to only use the newer cipher, or nothing could connect to it anymore. Thus there has to be the capability to work with multiple ciphers, so older ciphers can gradually be phased-in across systems and older cipher phased-off. Pretty sure the two other commenters are mostly researchers with no real world software deployment to manage. Otherwise they wouldn't be so strong against agility. Fact is a system with no agility is dead in the water because it can't evolve.

masklinn 6y ago
This is exactly backwards. In theory cipher agility is useful so you can upgrade your suite over time, in practice it’s a terrible idea because it will, and has time and again, lead to downgrade attacks. Crypto researchers have learned this fact of life the hard way, crypto systems are becoming less “agile” over time because this agility means it’s preemptively broken.