Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

eric.mann.blog

Post reply on HN
Print view View original

11–20 of 23 posts

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

#11

Post by steventhedev »

yammosk wrote: post #9

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.

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.

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

#12

Post by mhluongo »

bob1029 wrote: post #2

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.

Again and again, we've seen that HSMs aren't secure against physical access of the device.

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

#13

Post by MattPalmer1086 »

yammosk wrote: post #9

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.

As opposed to the whim of one person?

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

#14

Post by eamann »

bob1029 wrote: post #2

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.

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.

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

#15

Post by eamann »

xg15 wrote: post #7
poppadom1982 wrote: post #5

> 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 a…

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.…

Oblivious transfer - party A creates two random values (x_0 and x_1) and sends them _both_ to party B.

Party B picks one and uses that to compute future values that are sent back to party A _but without telling party A which of the two values they picked_.

In this example I'm hand-wavey because the production math is complicated and confusing - I took a vastly simplified approach that still works functionally for the demonstration without fully implementing the OT protocol.

> what happens if an owner drops out or you want to introduce a new one? what happens if you want to change the quorum?

In either of those scenarios, assuming you still have quorum, you can regenerate keyshares for the new group for the same public key (and underlying yet unknown private key) by re-running the ceremony with the new participants. Production implementations of the protocol fully flesh this out.

> traditional authentication ...

I wouldn't use TSS in that setup. Traditional auth + MFA is more than adequate. The better use case would be where you have a group that needs to demonstrate consensus (like governance for a programming language, multiple parties involved in signing an application release, or even an HOA that needs to vote on policies). In all of these, you'd take an M of N approach (rather than the simplified 2 of 2) for achieving quorum.

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

#16

Post by eamann »

yammosk wrote: post #9

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.

It's to protect against the whims of a small set of people.

If one person holds the signing key to do something critical in your system, they're both a single point of failure and a huge security risk all in one. If you distribute that key to, say, 5 different people you've mitigated the single point of failure. But now you have 5 folks who can act potentially unilaterally.

Using a 3 of 5 TSS setup, you've still mitigated the single point of failure (any one or even two folks can go offline and you can still operate) while also protecting against unilateral action. It's a mathematically-enforced version of the "two-man rule." Similar to the way Cloudflare's Red October tool used to work by splitting things between parties: https://blog.cloudflare.com/red-october-cloudflares-open-sou...

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

#17

Post by bob1029 »

mhluongo wrote: post #12
bob1029 wrote: post #2

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.

Again and again, we've seen that HSMs aren't secure against physical access of the device.

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?

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

#18

Post by xg15 »

eamann wrote: post #15
xg15 wrote: post #7

Earlier quoted context omitted.

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.…

Oblivious transfer - party A creates two random values (x_0 and x_1) and sends them _both_ to party B. Party B picks one and uses that to compute future values that are sent back to party A _but without telling party A which of the two values they picked_. In this example I'm hand-wavey because the production math is complicated and confusing - I took a vastly simplified approach that still works functionally for the…

Ah, that makes a lot more sense. Thanks for the additional explanations!

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

#19

Post by yammosk »

MattPalmer1086 wrote: post #13
yammosk wrote: post #9

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.

As opposed to the whim of one person?

What secret is controlled by one person? That's just not how businesses manage secrets.

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

#20

Post by MattPalmer1086 »

yammosk wrote: post #19
MattPalmer1086 wrote: post #13

Earlier quoted context omitted.

As opposed to the whim of one person?

What secret is controlled by one person? That's just not how businesses manage secrets.

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!
Post reply on HN