7 ms·

Algorithm Agility?

30 points by moks 5y ago

upofadown 5y ago
If someone suddenly breaks the stuff based on the 25519 curve there are going to be a lot of very unhappy people. I am still waiting for an explanation of why this particular curve is immune to such a breakthrough.
- tatersolid 5y ago
  A lot of research went in to Curve25519; multiple decades of ECC academic investigation created a set of criteria for safety: See https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/
  - upofadown 5y ago
    Curve25519 has only been around for something like 10 years. A catastrophic attack on it would presumably involve new ideas specific to that particular or class of curves. Otherwise any completely new system would have to be considered secure, as it would not suffer from any of the issues of any of the older systems. My understanding is that new elliptic curves can have entirely new characteristics not shared by older curves.
    - tatersolid 5y ago
      Curve25519 was introduced in 2005 and seems to have had rapid uptake in academia due to the reputation of one of the authors (djb). So Curve25519 has had 16 years of widespread academic scrutiny. That’s “battle-tested” by modern cryptographic standards.
- tptacek 5y ago
  Nobody thinks it is. Curve25519 being invincible is not the premise behind the shift away from "agility".
RcouF1uZ4gsC 5y ago
> should developers just blast the key-bits into base64 and ship that? I would argue given the key lengths of ed25519, not even to do base64, but just do hex encoding. Sure it is a little longer, but in return you get much simpler encoding and decoding, no worries about flavors of base64 or padding. In addition, hex encoding is much easier to verbally communicate to someone versus base64. In a security context, I think making things as simple as possible has big benefits.
- upofadown 5y ago
  Split the difference with base 32? More efficient than hex, you can leave out the 4 easiest letters to confuse with digits and no upper/lower case problem. Verbal communication is a problem with any system that uses letters. In hex for example; 3, B, C, D and E all sound very much the same.
  - RcouF1uZ4gsC 5y ago
    > In hex for example; 3, B, C, D and E all sound very much the same. We have a standard way of dealing with that in the form the NATO phonetic alphabet. So 3BCDE would be “Tree Bravo Charlie Delta Echo”
skybrian 5y ago
I'm not a any kind of crypto expert, but I'm wondering if this looks like a config file? Let's say you have a JSON file that has one field, which is the key, base64-encoded. Maybe you won't change the algorithm, but still want to leave room to add another config parameter. The file format is obvious in a text editor and it's easy to add more stuff.
tptacek 5y ago
Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arrangements, etc), and, most importantly, have required updates to the entire protocol anyways. It's a bad idea and people shouldn't build it into new systems. Version the protocol instead, and plan on making it straightforward to upgrade the protocol and lock out old versions.
- MaxBarraclough 5y ago
  Relevant Wikipedia article: https://en.wikipedia.org/wiki/Downgrade_attack https://en.wikipedia.org/wiki/Downgrade_attack
- QuinnWilton 5y ago
  And all of this is to say nothing of the frankly embarrassing problems that have plagued JWT as a result of algorithm agility (alg=none). Removing agility from JWT wouldn't make it a good specification, but it would certainly make it a better specification.
  - emteycz 5y ago
    What is a good alternative?
    - QuinnWilton 5y ago
      This is a really tough question to answer, because the answer depends on what you're using JWT for. JWT crams as much functionality into the format as possible, and most of that functionality isn't needed for most use cases. This means that offering an alternative requires knowing some context about what you need out of JWT in the first place. That being said, for most purposes, you can do worse than using either mutual TLS or Macaroons [0]. As always with cryptography though, the devil is in the details, so for a more thorough discussion, check out @tptacek's "A Child's Garden of Inter-Service Authentication Schemes" [1]. It's one of my favourite treatments of the topic, and discusses the tradeoffs of a few different techniques for different use-cases. [0] https://en.wikipedia.org/wiki/Macaroons_(computer_science) https://en.wikipedia.org/wiki/Macaroons_(computer_science) [1] https://latacora.micro.blog/a-childs-garden/ https://latacora.micro.blog/a-childs-garden/

30 points by moks 5y ago

If someone suddenly breaks the stuff based on the 25519 curve there are going to be a lot of very unhappy people. I am still waiting for an explanation of why this particular curve is immune to such a breakthrough.

tatersolid 5y ago
A lot of research went in to Curve25519; multiple decades of ECC academic investigation created a set of criteria for safety: See https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/
- upofadown 5y ago
  Curve25519 has only been around for something like 10 years. A catastrophic attack on it would presumably involve new ideas specific to that particular or class of curves. Otherwise any completely new system would have to be considered secure, as it would not suffer from any of the issues of any of the older systems. My understanding is that new elliptic curves can have entirely new characteristics not shared by older curves.
  - tatersolid 5y ago
    Curve25519 was introduced in 2005 and seems to have had rapid uptake in academia due to the reputation of one of the authors (djb). So Curve25519 has had 16 years of widespread academic scrutiny. That’s “battle-tested” by modern cryptographic standards.
tptacek 5y ago
Nobody thinks it is. Curve25519 being invincible is not the premise behind the shift away from "agility".

RcouF1uZ4gsC 5y ago

> should developers just blast the key-bits into base64 and ship that? I would argue given the key lengths of ed25519, not even to do base64, but just do hex encoding. Sure it is a little longer, but in return you get much simpler encoding and decoding, no worries about flavors of base64 or padding. In addition, hex encoding is much easier to verbally communicate to someone versus base64. In a security context, I think making things as simple as possible has big benefits.

upofadown 5y ago
Split the difference with base 32? More efficient than hex, you can leave out the 4 easiest letters to confuse with digits and no upper/lower case problem. Verbal communication is a problem with any system that uses letters. In hex for example; 3, B, C, D and E all sound very much the same.
- RcouF1uZ4gsC 5y ago
  > In hex for example; 3, B, C, D and E all sound very much the same. We have a standard way of dealing with that in the form the NATO phonetic alphabet. So 3BCDE would be “Tree Bravo Charlie Delta Echo”

skybrian 5y ago

I'm not a any kind of crypto expert, but I'm wondering if this looks like a config file? Let's say you have a JSON file that has one field, which is the key, base64-encoded. Maybe you won't change the algorithm, but still want to leave room to add another config parameter. The file format is obvious in a text editor and it's easy to add more stuff.

tptacek 5y ago

Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arrangements, etc), and, most importantly, have required updates to the entire protocol anyways. It's a bad idea and people shouldn't build it into new systems. Version the protocol instead, and plan on making it straightforward to upgrade the protocol and lock out old versions.

MaxBarraclough 5y ago
Relevant Wikipedia article: https://en.wikipedia.org/wiki/Downgrade_attack https://en.wikipedia.org/wiki/Downgrade_attack
QuinnWilton 5y ago
And all of this is to say nothing of the frankly embarrassing problems that have plagued JWT as a result of algorithm agility (alg=none). Removing agility from JWT wouldn't make it a good specification, but it would certainly make it a better specification.
- emteycz 5y ago
  What is a good alternative?
  - QuinnWilton 5y ago
    This is a really tough question to answer, because the answer depends on what you're using JWT for. JWT crams as much functionality into the format as possible, and most of that functionality isn't needed for most use cases. This means that offering an alternative requires knowing some context about what you need out of JWT in the first place. That being said, for most purposes, you can do worse than using either mutual TLS or Macaroons [0]. As always with cryptography though, the devil is in the details, so for a more thorough discussion, check out @tptacek's "A Child's Garden of Inter-Service Authentication Schemes" [1]. It's one of my favourite treatments of the topic, and discusses the tradeoffs of a few different techniques for different use-cases. [0] https://en.wikipedia.org/wiki/Macaroons_(computer_science) https://en.wikipedia.org/wiki/Macaroons_(computer_science) [1] https://latacora.micro.blog/a-childs-garden/ https://latacora.micro.blog/a-childs-garden/