51–60 of 69 posts
Does this count as an instance of 'don't roll your own crypto'?
That said shamir's secret sharing is one of the easiest constructions to reason about so I think the risk is much smaller there
`killall` was different on Solaris than Linux; too. Learning those differences by coming to Linux from Solaris was liberating; there were less limits generally. The other way around was less fun: as in this example, code that had run fine before was now subject to weird behaviors that were caused by underlying system assumptions being different. At least Solaris usually had decent documentation.
Most descriptions of and implementations of Shamir secret sharing are a bit intimidating. If however you just need a system where any two people with shares can reconstruct the secret then SSS can be very short and simple. Let a0 = the secret p = a prime number > a0 a1 = a random integer in [1, p-1] Assign each person who is to receive a share of the secret an ID in [1, p-1]. It is OK to simply assign IDs sequentiall…
https://gist.github.com/ll931110/985a4ec711c6711b120846be05e...
OK, since we're pitching our SSS implementations here in comments, I welcome everyone to check out BananaSplit, https://bs.parity.io Not sure about year 2023, but at the time I wrote it for my previous employer there was nothing remotely usable for regular user. Thus, BananaSplit. It doesn't allow you to specify many parameters (just the number of shards, and then requires 50%+1 to recover); aimed at printed backups…
I'm not sure the offline mode instructions for Firefox are accurate.
We probably shouldn't even bother recommending browser-specific offline modes; I've created an issue in the project's repo to reword that piece by the next release.
OK, since we're pitching our SSS implementations here in comments, I welcome everyone to check out BananaSplit, https://bs.parity.io Not sure about year 2023, but at the time I wrote it for my previous employer there was nothing remotely usable for regular user. Thus, BananaSplit. It doesn't allow you to specify many parameters (just the number of shards, and then requires 50%+1 to recover); aimed at printed backups…
Doesn't seem to understand that the file is local when opening in Chrome on Android, interesting.
That's a shame — things were definitely different in 2019 when I built the initial version; and mobile browsers were definitely a target I had in mind for the tool (especially when it comes to the recovery).
Instead of wrapping the existing tool into a mobile app, I'm thinking about standardizing the QR code format from the tool a bit more — so multiple, more task-specific recovering mobile apps would be possible. (Like, the one in your password manager detecting certain internal text formatting and importing the entries automatically and such).
Earlier quoted context omitted.
Aaah, we had something like this happen to a k8s cluster that had secrets stored in a HC Vault. The vault got sealed and the keys lost. That was it...
How did you recover?
Does this count as an instance of 'don't roll your own crypto'?
I think it's more of an instance of "it works on my computer"; not testing on an environment sufficiently similar to production, and applying a change that cannot be rolled back.
A better solution may have been multi-key support. Some test records could be encrypted with the new key and the system let run for a week or so. Then all new records could start being encrypted with the new key and run for another week. Once everything looks good a background job could be started to convert all data to the new key. Then the old key can be retired (other than as needed for backups).
Although they did have the key printed in an envelope, so it sounds like that would have been an effective recovery solution once they remembered.
Wow, he shredded the only copy of the key his database backups were encrypted with.