[HN Gopher] Shamir Secret Sharing
___________________________________________________________________
Shamir Secret Sharing
Author : yankcrime
Score : 222 points
Date : 2023-08-11 10:38 UTC (12 hours ago)
(HTM) web link (max.levch.in)
(TXT) w3m dump (max.levch.in)
| EGreg wrote:
| 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.
| nullc wrote:
| 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.
| EGreg wrote:
| 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?
| croes wrote:
| Always test with real values even passwords
| kedean wrote:
| 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 wrote:
| "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.
| nailer wrote:
| > 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 wrote:
| Was just reading about this SSS technique yesterday and now its
| on HN
| threesevenths wrote:
| This story has been posted numerous times in the last fortnight.
| It's a great story but certainly undeserving of a reread
| dxdm wrote:
| I read HN almost every day, and this is the first time I've
| seen the link. I'm glad it was posted again.
| AstralStorm wrote:
| Oh boy, one of them classic stories of "we accidentally pushed a
| development setup into production".
|
| What's worse, partially.
| Hendrikto wrote:
| Did you read the article? There was nothing accidental about
| this. It was done with a lot of planning and premeditation.
| AstralStorm wrote:
| 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.
| striking wrote:
| Not every company has a staging environment...
| dcminter wrote:
| Particularly since, by my recollection, 20 years ago a
| separate staging environment was the exception not the
| rule.
| lmm wrote:
| As the saying goes, everyone has a test environment, some
| are lucky enough to have a separate production
| environment.
| mannykannot wrote:
| _" 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.
| Cthulhu_ wrote:
| 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.
| BtM909 wrote:
| See previous discussion(s):
| https://news.ycombinator.com/item?id=36941720
| mdaniel wrote:
| 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
| imadj wrote:
| 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 wrote:
| The URL is different, so it probably slipped under the dupe
| radar
| distcs wrote:
| Probably not enough people have flagged it as [dupe]?
| seniorThrowaway wrote:
| 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
| s1mplicissimus wrote:
| 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.
| mmmmmmtoes wrote:
| [dead]
| nailer wrote:
| 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.
| tonicanada wrote:
| I found this topic so interesting that I wrote an article about
| it! https://medium.com/gitconnected/sharing-a-secret-with-
| polyno...
| NovemberWhiskey wrote:
| > _original news of our move to the US was delivered to them via
| a posted letter, snail mail, not FidoNet email!_
|
| _net_ mail, not _e_ mail :-)
|
| 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 wrote:
| Printed out the master key and stored it in a safe...
|
| Wonder if that printer kept a copy...?
| AstralStorm wrote:
| 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.
| antran22 wrote:
| 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.
| knallfrosch wrote:
| This. You could tank the company by stealing their funds or
| simply burning the secret-storing computers down
| bombcar wrote:
| Risk mitigation is always about mitigating- making
| something harder or more impossible than something else.
| Nothing is perfect but some things are better.
| mmmmmmtoes wrote:
| [dead]
| MerelyMortal wrote:
| Tamper seals are also easily non-evidently bypassed.
| jgalt212 wrote:
| If your adversaries are that sophisticated and / or have that
| much intimate physical access, I do not envy you.
| nickdothutton wrote:
| 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.
| [deleted]
| numair wrote:
| 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 wrote:
| [citation needed]
|
| I'd totally read that, are there any articles?
___________________________________________________________________
(page generated 2023-08-11 23:01 UTC)