Shamir Secret Sharing

https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of

by yankcrime • 3 years ago

238 42 3 years ago

max.levch.in

This story has been posted numerous times in the last fortnight. It’s a great story but certainly undeserving of a reread

dxdm• 3 years ago

I read HN almost every day, and this is the first time I've seen the link. I'm glad it was posted again.

threesevenths2• 3 years ago

It is a good story.

BtM909• 3 years ago

See previous discussion(s): https://news.ycombinator.com/item?id=36941720

mdaniel• 3 years ago

yeah, it evidently got posted on some social media because it's been just rampantly resubmitted https://news.ycombinator.com/from?site=max.levch.in

I really wish HN had the mildest of dupe checking, as anyone who does care about the topics of these repeated reposts has to go and read all the different threads

NovemberWhiskey• 3 years ago

original news of our move to the US was delivered to them via a posted letter, snail mail, not FidoNet email!

netmail, not email :-)

As the knower of the code, for the safe, in the escorted-only data center, that contains one of our Vault key shares, this story resonates.

londons_explore• 3 years ago

Printed out the master key and stored it in a safe...

Wonder if that printer kept a copy...?

AstralStorm3• 3 years ago

Better yet, wonder if someone can steal that safe, open it, then replace it with an identical looking one with the same note?

Two words: tamper seals

An envelope is easily steamed open.

And you better hope nobody bypasses the alarm. Or you won't know to check the seals until it's way too late.

antran222• 3 years ago

It all boil down to trust. He gave it to somebody he trust, who also have their stake in PayPal. If you couldn't even trust the General Legal Counsel of your company, a secrets key might not be the thing you needed to worry about then.

mmmmmmtoes• 3 years ago

That seems a little paranoid, even for a company storing card data for millions of people.

jgalt212• 3 years ago

If your adversaries are that sophisticated and / or have that much intimate physical access, I do not envy you.

MerelyMortal• 3 years ago

Tamper seals are also easily non-evidently bypassed.

AstralStorm3• 3 years ago

Oh boy, one of them classic stories of "we accidentally pushed a development setup into production".

What's worse, partially.

Hendrikto• 3 years ago

Did you read the article? There was nothing accidental about this. It was done with a lot of planning and premeditation.

AstralStorm3• 3 years ago

There was no testing. No staging setup.

So, premeditated or not, it counts as pushing development code into production. The accidentally part I believe is because someone didn't know any better.

Cthulhu_• 3 years ago

The oversight is that they developed and tested it on Linux, created the file on Linux as well, but used it on Solaris, using an operating system tool to enter the password that had different behaviour on Solaris (stripping anything beyond 8 characters in length because... nobody needs long passwords, right?).

It still happens today though, and subtle differences between computers or e.g. CPU architectures can and will still occur. It's really difficult or cost prohibitive to set up a DTAP or similar where every step is production-like; I can imagine it's similarly complex on modern day distributed systems / microservices.

mannykannot• 3 years ago

"There was nothing to do, except to hit rewind...

"A cursory look at the master key file date told me that no, it wouldn’t be OK at all. The file sitting on cryptoserv wasn’t from last night, it was created just a few minutes ago. During the Salt-n-Pepa-themed push from stage, we overwrote the master key file with the stage version... Not only that, the push script appears to have also wiped out the backup of the old key, so the database backups we have encrypted with the old key are likely useless."

So, despite all the planning and premeditation, they ended up doing exactly what AstralStorm says. An undesirable outcome does not stop being an accident if it is an unanticipated and unintended consequence of a planned action. Being in a crisis because you have forgotten how you planned to avoid it also counts as an accident.

As for the "Salt-n-Pepa-themed push": personally, I would have avoided all possible distractions at a time like this. Turning off phones (except maybe one, monitored by someone for whom that was their only job) would not have been unreasonable.

s1mplicissimus• 3 years ago

umm so he had the master key printed out as backup anyway so there was never really any danger if i read correctly. clickbait?

Ha. I forgot all about it, but in a bout of “what if it doesn’t work” paranoia, I printed out the base64-encoded master key when we had generated it the night before, stuffed it into an envelope, and gave it to John for safekeeping.

nailer2• 3 years ago

That's correct. But also in his stress, he forgot about this. It's a good lesson about how stress can make people do irrational things, like forget the backup they just made.

numair• 3 years ago

Oh! We are finally going to talk about how PayPal was utterly owned by Russian cyber gangs that made a mockery of the idea that these guys were fraud detection geniuses?

checks article

Oh, wait, nevermind. More “folklore.”

KaiserPro• 3 years ago

[citation needed]

I'd totally read that, are there any articles?

croes• 3 years ago

Always test with real values even passwords

kedean• 3 years ago

I dont think that would have helped, half the issue was mixing environments. The master key was generated on Linux, where the passphrases weren't truncated, but it was being used on Solaris where they were. If it had been generated on Solaris or used in Linux the problem wouldn't be there. To find this in testing, you'd have to predict that "data being generated one place and used on another" could be a vector for bugs, and that's not necessarily obvious

hutzlibu• 3 years ago

"you'd have to predict that "data being generated one place and used on another" could be a vector for bugs, and that's not necessarily obvious"

It seems you never had to deal with file encodings? And windows upper lowercase does not matter, compared to linux where it does matter?

But yes, obvious was none of that to me, I naivly assumed, data should be just data, until I change it. Like they did.

nailer2• 3 years ago

Solaris had a “special feature”: any passphrase entered that was longer than 8 characters long was automatically reduced to that length anyway.

Solaris is known for having stupid defaults. I once had a box refuse to boot because the whitespace in a config file used tabs rather than spaces.

testemailfordg2• 3 years ago

Was just reading about this SSS technique yesterday and now its on HN

_xivi• 3 years ago

Out of curiosity, How is this post not a [dupe] and managed to reach the front page even though it had its fair share not even 10 days ago

ergl• 3 years ago

The URL is different, so it probably slipped under the dupe radar

distcs• 3 years ago

Probably not enough people have flagged it as [dupe]?

seniorThrowaway• 3 years ago

this brings up old memories of being bitten sometime by this Solaris "feature" although it's been too many years to remember the exact details. It was one of those things that made me realize Linux was actually a much more usable system from a day to day admin point of view, along with package managers.

Edit: another one was Solaris defaulting to the obsolete unix crypt function based on the Enigma machine

nickdothutton• 3 years ago

As soon as getpass was mentioned, I knew. It’s worth reminding people that in these matters, print on paper is a weapon, know when to use it.

EGreg2• 3 years ago

While it’s exciting to read this kind of stuff, and I am glad to see a fellow Soviet emigre come and found a company in the Valley, I have to comment on just how much control is centralized in the hands of a few people, that millions of people come to trust with their data and their money!

This is essential commentary to Shamir Secret Sharing, because it requires a trusted dealer, unlike BLS and other bilinear technqiues.

Look at this:

Whatever key that was, it wasn’t the one I generated the day before: only one copy existed, the one I copied to cryptoserv from my computer the night before. Zero copies existed now. Not only that, the push script appears to have also wiped out the backup of the old key, so the database backups we have encrypted with the old key are likely useless.

So with SSS just have to take his word for it, that he didn’t have a copy of the key back on his computer. Zero copies existed? It’s not like he made another copy of it? Surely he is a reliable narrator and we can trust that at least, right? Actually, NOPE:

A few hours later, John, our General Counsel, stopped by my cubicle to ask me something. The day before I apparently gave him a sealed envelope and asked him to store it in his safe for 24 hours without explaining myself. He wanted to know what to do with it now that 24 hours have passed. Ha. I forgot all about it, but in a bout of “what if it doesn’t work” paranoia, I printed out the base64-encoded master key when we had generated it the night before, stuffed it into an envelope, and gave it to John for safekeeping. We shredded it together without opening and laughed about what would have never actually been a company-ending event.

So the lawyer could have conceivably hired someone to break into the database, steal credit card numbers and salami-slice some value for years, or launch one big attack on the entire database:

https://en.wikipedia.org/wiki/Salami_slicing_tactics

Having ONE SET OF KEYS or passwords to access THE ENTIRE DATABASE is the epitome of the whole Digital Feudalism that we have today! But that’s what we have in Web2. Sam Bankman Fried is just one example. This is where Web3 is so different. Everyone has their own keys, and they can only do what the are allowed to by the smart contract code. You reduce the attack surface massively. You reduce the need for celebirties like Max Levchin, and his stories, as much as I like them.

Some people on HN might dislike Web3 and smart contracts, and I do agree that blockchains arent a very efficient technology for implementing them, but the idea of being able to trust the code is crucial for our society. Otherwise, the closest we can get to it is this:

https://signal.org/blog/private-contact-discovery/

In an age where Google wants to implement attestations of CLIENTS in Chrome, we as a society should be demanding the other way: proving that the CODE AND DATA cannot be tampered with. SGX extensions are far worse than smart contracts to secure large amounts of value, whether it’s currency balances, votes, or other data.

Anyway, for the crypto side I will just say that BLS signatures are far superior to SSS. I mean cryprography when I say crypto. It has NOTHING to do with blockchain, but rather with generation of private keys and verifying transactions that were posted to some decentralized network. Use BLS. SSS is outdated.

nullc2• 3 years ago

One doesn't need BLS to avoid having a trusted dealer in the context of signatures-- though signatures are unrelated and irrelevant to the subject of this post. But plain ECC signatures without any bilinear group can do threshold signatures.

(also any BLS signature that implements a single key threshold that's indistinguishable from a single key will be using SSS under the hood to implement the threshold, though I agree end users should probably never be using SSS directly)

SGX extensions are far worse than smart contracts to secure large amounts of value, whether it’s currency balances, votes, or other data.

"smart contracts" as they are don't provide confidentiality, in fact they're generally extra toxic to confidentiality.

EGreg2• 3 years ago

I am not sold on the value of confidentiality for everything. The governments are all moving to gradually ban end-to-end encryption, as they worry about “terrorism” etc. But no one is moving to ban cryptographic signatures. They help with self-sovereignty and to ensure integrity of many things including code. Smart contracts can help ensure the immutability of code and I don’t know of any other mechanism that’s widely deployed today that can guarantee the code and data won’t be tampered with. Do you?

tonicanada• 3 years ago

I found this topic so interesting that I wrote an article about it! https://medium.com/gitconnected/sharing-a-secret-with-polyno...

Shamir Secret Sharing

Related Stories