5 ms·

Why One Key Shouldn't Rule Them All: Threshold Signatures for the Rest of Us

17 points by eamann 6mo ago

bob1029 6mo ago
The article does touch on HSMs but might be missing the point of them? > A compromised server no longer means a compromised key Proper use of an HSM means that even the owner of the private key is not allowed to access it. You sign your messages within the secure context of the HSM. The key never leaves. It cannot become compromised if the system is configured correctly.
- tjoff 6mo ago
  You can't get the private key but you can sign with it, which is still plenty bad.
  - bob1029 6mo ago
    The private key should be tightly scoped to its context of use. I would definitely agree with you if it's one key that rules the entire kingdom.
    - tjoff 6mo ago
      Not sure I follow? Lets say it is limited to one use only, sign an app. Since I've got control of the box I can now use it to sign any app. Isn't that bad enough?
- goodpoint 6mo ago
  No, if an HSM is compromised everything is lost.
- mhluongo 6mo ago
  Again and again, we've seen that HSMs aren't secure against physical access of the device.
  - bob1029 6mo ago
    Can you point me to an example of a FIPS level 3+ certified device having its private keys compromised due to a defeat of the tamper resistant boundary?
    - mhluongo 6mo ago
      Here are a couple examples of physical access leading to key extraction. You're welcome to be pedantic (those are side channel attacks, they don't defeat the boundary!) but one way or another, physical access wins. https://www.cl.cam.ac.uk/~rnc1/descrack/ https://www.cl.cam.ac.uk/~rnc1/descrack/ https://ninjalab.io/eucleak/ https://ninjalab.io/eucleak/
- eamann 6mo ago
  You're correct there that proper use means even the owner can't access it. But in a single key scenario they can still act unilaterally. The advantage of TSS is the removal of that level of unilateral action.
poppadom1982 6mo ago
> The Core Idea > Enter X > How It Works (Without the PhD) > Why Y Should Care ...and an incredibly handwavy shallow explanation of why this actually works ("Through a clever sequence of oblivious transfers and what’s called multiplicative-to-additive share conversion, they each compute a partial signature.") I don't get it. If you want a blog, write a blog. If you don't want a blog, don't write a blog. But why use an LLM to create a slopblog? It just wastes EVERYONE's time and energy. How disappointing.
- xg15 6mo ago
  Not sure if it's AI slop yet, but I also found the core part (the "oblivious transfers") to be explained too handwavy to really understand the properties of this system. I don't want to know all the mathematical details, but I do want to understand who is exchanging what data with whom. "oblivious transfer" doesn't tell me anything here. The other (maybe more interesting) question is how this tech would be deployed. So ok, we have a system, where something can only be signed/decrypted/encrypted/etc if several parties are in agreement. Who should the parties be? How is the threshold itself actually managed? OP also seems to drift between different usage scenarios here: - some sort of collectively owned good (like the DAO or resources in a cooperative?) - seems straightforward on a technical level (every owner has a partial key) but also a niche usecase and quite inflexible: What happens if an owner drops out or you want to introduce a new one? What happens if you want to change the quorum? - traditional authentication of individual users against a server, in a federated setup like the fediverse: Seems like the most practical usecase: One party is the user, the other is the server, the verifying party would be other servers of the network. But then you have to pick your poison by how you set the quorum: Either the quorum is "any party can decrypt the data", at which point you're not better than normal password auth; or "both parties are needed", which would protect against the user or the server accidentally leaking the key - but then you're back to "single point of failure" if any party accidentally loses the key. - the last scenario would be server-side keys that could cause massive problems if they leaked. But I don't understand at all who should be the other parties here. Also how would this be better than HSMs?
  - eamann 6mo ago
yammosk 6mo ago
Even just on a theoretical level I am not really sure the use case of this system. For most keys like ssl certs, this is just too impractical. For anything that has significant business value (like the iOS signing key), I don't think any business would give up all control of such a key to the whims of 3 out of 5 people.
- steventhedev 6mo ago
  The entire point of this is that the complexity is encapsulated on the signing side - not the verifier. So it's more that you would split the keys between systems you control - say the reverse proxy and the application server. Or one that's checked into your version control (representing that it is your company's code that's running) and one that lives on the server (representing that it is a server your company controls). Or to take your example - a key in the repo, a key from the dev, and a key from the build server.
- MattPalmer1086 6mo ago
  As opposed to the whim of one person?
  - yammosk 6mo ago
    What secret is controlled by one person? That's just not how businesses manage secrets.
    - MattPalmer1086 6mo ago
      You are not consistent here. When talking about only needing a single signing key you say that is not subject to the whim of one person. When discussing an N-out-of-M scheme, you think that it's just down to the whims of whoever is in that group. That's just not how business manages secrets!
      - yammosk 6mo ago
        I just don't think that keys would be accessible by only one person in either scenario for any large business. The article suggests this 3/5 key needed system prevents issues but I don't think so in practical terms. My suspicion is it thinks there is only one person per key but I think in any business scenario a team would have access to all of them negating the benefits. I don't think that's inconsistent, perhaps just my misunderstanding of what this proposed.

17 points by eamann 6mo ago

The article does touch on HSMs but might be missing the point of them? > A compromised server no longer means a compromised key Proper use of an HSM means that even the owner of the private key is not allowed to access it. You sign your messages within the secure context of the HSM. The key never leaves. It cannot become compromised if the system is configured correctly.

tjoff 6mo ago
You can't get the private key but you can sign with it, which is still plenty bad.
- bob1029 6mo ago
  The private key should be tightly scoped to its context of use. I would definitely agree with you if it's one key that rules the entire kingdom.
  - tjoff 6mo ago
    Not sure I follow? Lets say it is limited to one use only, sign an app. Since I've got control of the box I can now use it to sign any app. Isn't that bad enough?
goodpoint 6mo ago
No, if an HSM is compromised everything is lost.
mhluongo 6mo ago
Again and again, we've seen that HSMs aren't secure against physical access of the device.
- bob1029 6mo ago
  Can you point me to an example of a FIPS level 3+ certified device having its private keys compromised due to a defeat of the tamper resistant boundary?
  - mhluongo 6mo ago
    Here are a couple examples of physical access leading to key extraction. You're welcome to be pedantic (those are side channel attacks, they don't defeat the boundary!) but one way or another, physical access wins. https://www.cl.cam.ac.uk/~rnc1/descrack/ https://www.cl.cam.ac.uk/~rnc1/descrack/ https://ninjalab.io/eucleak/ https://ninjalab.io/eucleak/
eamann 6mo ago
You're correct there that proper use means even the owner can't access it. But in a single key scenario they can still act unilaterally. The advantage of TSS is the removal of that level of unilateral action.

poppadom1982 6mo ago

> The Core Idea > Enter X > How It Works (Without the PhD) > Why Y Should Care ...and an incredibly handwavy shallow explanation of why this actually works ("Through a clever sequence of oblivious transfers and what’s called multiplicative-to-additive share conversion, they each compute a partial signature.") I don't get it. If you want a blog, write a blog. If you don't want a blog, don't write a blog. But why use an LLM to create a slopblog? It just wastes EVERYONE's time and energy. How disappointing.

xg15 6mo ago
Not sure if it's AI slop yet, but I also found the core part (the "oblivious transfers") to be explained too handwavy to really understand the properties of this system. I don't want to know all the mathematical details, but I do want to understand who is exchanging what data with whom. "oblivious transfer" doesn't tell me anything here. The other (maybe more interesting) question is how this tech would be deployed. So ok, we have a system, where something can only be signed/decrypted/encrypted/etc if several parties are in agreement. Who should the parties be? How is the threshold itself actually managed? OP also seems to drift between different usage scenarios here: - some sort of collectively owned good (like the DAO or resources in a cooperative?) - seems straightforward on a technical level (every owner has a partial key) but also a niche usecase and quite inflexible: What happens if an owner drops out or you want to introduce a new one? What happens if you want to change the quorum? - traditional authentication of individual users against a server, in a federated setup like the fediverse: Seems like the most practical usecase: One party is the user, the other is the server, the verifying party would be other servers of the network. But then you have to pick your poison by how you set the quorum: Either the quorum is "any party can decrypt the data", at which point you're not better than normal password auth; or "both parties are needed", which would protect against the user or the server accidentally leaking the key - but then you're back to "single point of failure" if any party accidentally loses the key. - the last scenario would be server-side keys that could cause massive problems if they leaked. But I don't understand at all who should be the other parties here. Also how would this be better than HSMs?
- eamann 6mo ago

yammosk 6mo ago

Even just on a theoretical level I am not really sure the use case of this system. For most keys like ssl certs, this is just too impractical. For anything that has significant business value (like the iOS signing key), I don't think any business would give up all control of such a key to the whims of 3 out of 5 people.

steventhedev 6mo ago
The entire point of this is that the complexity is encapsulated on the signing side - not the verifier. So it's more that you would split the keys between systems you control - say the reverse proxy and the application server. Or one that's checked into your version control (representing that it is your company's code that's running) and one that lives on the server (representing that it is a server your company controls). Or to take your example - a key in the repo, a key from the dev, and a key from the build server.
MattPalmer1086 6mo ago
As opposed to the whim of one person?
- yammosk 6mo ago
  What secret is controlled by one person? That's just not how businesses manage secrets.
  - MattPalmer1086 6mo ago
    You are not consistent here. When talking about only needing a single signing key you say that is not subject to the whim of one person. When discussing an N-out-of-M scheme, you think that it's just down to the whims of whoever is in that group. That's just not how business manages secrets!
    - yammosk 6mo ago
      I just don't think that keys would be accessible by only one person in either scenario for any large business. The article suggests this 3/5 key needed system prevents issues but I don't think so in practical terms. My suspicion is it thinks there is only one person per key but I think in any business scenario a team would have access to all of them negating the benefits. I don't think that's inconsistent, perhaps just my misunderstanding of what this proposed.