I made an app that lets you split a file into horcruxes
github.com
github.com
The state of the art codec is RaptorQ, I’ve got a Go library that uses the slightly older Raptor standard to do chunking
But to answer your question, yes, you could recover some of the file if you didn't get as many pieces as you needed. Been a year or so since I did any work with fountain codes, but I believe most implementations send all the chunks, followed by n error correction chunks, so it would depend on how many real chunks you got. The error corrections wouldn't get you anywhere though.
But, hey, this is really cool. It was probably really fun to write, and luminates a cool scheme that too few know anything about.
This is actually pretty useful, but sort of sad it drags the whole go ecosystem with it (who knows what go will look like in 20 years and if this app will still compile and work).
This is something which the CS community needs to solve, imho. I.e. provide an executable language with a formal specification that is guaranteed to be available indefinitely. And to make this more useful, other programming languages should provide back-ends targeting this language.
2. Split it into N + 1 horcruxes and distribute them to your N children; and a remaining piece to a lawyer;
3. Force them to all come together to decrypt the will for fairness.
BTW K of N cryptography is well known as Shamir’s Secret Sharing.
Don’t give that child a piece in the first place!
I thought this was a command!
> 3. Force them to all come together to decrypt the will for fairness.
This seems like a good recipe for ensuring integrity of the will, but it's hard (for me) to see how it ensures, or even promotes, fairness.
(Also, compelling presence seems like a strange side effect: the sort of person who would skip the reading of a will might not be motivated to ensure the fairness or integrity of the will anyway, so requiring their presence to verify it seems counterproductive.)
Note: thanks for spotting the typo. I corrected it.
A cautionary tale: Someone in my family died before getting his will sorted out, leaving a tangled mess of accounts and businesses. My mother was one of his executors, and they had to in effect remove themselves from the will because it was written before his children were born and they weren't mentioned (the lesson being if you have children or any one else you care about, get your will sorted out sooner rather than later - in this particularly case he was found dead in the morning without warning)
I heard of an individual who very specifically left one dollar to one of their children. The logic being, if said child hadn't been mentioned in the will at all, there could be a claim that they'd been inadvertently left out...
I'm super curious how that works in practice.
For instance if you have two of them you can freely dispose of 1/3 of your estate, the rest is shared equally between your children and spouse.
Relevant law (in French) : https://www.service-public.fr/particuliers/vosdroits/F606
Base64 encode the key, pad it with random data that matches the size of splitting into N-1 parts. Then split the encrypted file into N-1 b64 encoded parts. For lowish values of 'N', you could then just decrypt with each "key" until something readable emerges. The key size, algo, etc, could be prepended to each part in plaintext.
Or, if you want a variation where no parts are optional, a piece of the key in every split part, with a sufficiently long key.
1. the encryption key is the y-intercept of a line 2. each shared key ("horcrux" in the OP terminology) is a point along the line 3. more keys are simply more points on the line
Once you have any two keys, you can fully define the line and recover the Y intercept.
This gives you really strong guarantees because each point on its own reveals nothing about the y-intercept; without satisfying the M-of-N threshold, the value could still be anything.
Generalizing this to the M-of-N case simply involves increasing the order of the curve (ie line -> parabola -> ...)
> A) It's pretty close! You can't allow any one horcrux to be used to resurrect the original file (and why would you that would be useless) but you can allow two horcruxes to do it (so only off by one). Checkmate HP fans.
Not buying it, and the fact that this is the first FAQ is evidence that the author doesn't really either. A better fit to Tom Riddle's horcrux would simply be a lossy compression copy of the file. Which would admittedly be pretty useless, maybe unless the copy contains a lossy copy of your soul.
But then Virgin Galactic is also a pretty good name even though they haven't yet left the solar system. That should be his defense: it's just a cool name.
ETA: For even more accuracy, increase the 'readability' of the file(for text only I guess) with each horcrux deleted. Allow them to be added one by one so the original file slowly 'increases it's power'.
Name of my next poetry anthology, right there.
Virgin Galactic hasn't even got to the Karman line - they've topped out at 90km.
Correct me if I'm wrong, but my memory is that a horcrux is literally a piece of your original, whole soul. So, if you create one horcrux (as seems to have been the standard practice prior to Tom Riddle), you continue living from then on with only half a soul. Voldemort's capacity for evil came partly from having only 1/7 of a soul in his body.
So I actually think the name kind of fits. Where it loses me a bit is that you can recreate the original file without all of the Horcruxes. Simply splitting the bytes into separate files would be closer IMO.
He was plenty evil before he made horcruxes.
Splitting the bytes would be closer only for file types that work (maybe not to the fullest) as 1/n pieces. OP misunderstood and thought that Tom Riddles soul was in full when he reconstructed his body, but it was actually only 1/7, and terribly maimed.
This app seams to use Shamir's Secret Sharing, this is something where I am not familiar with, but from how far I understand the Wikipedia article about it. it works roughly the same but it is more general.
I'm interested to see if people will actually use this. If anyone has some additional explanations about the differences between these algorithms then that would be very appreciated.
i.e. if I just split the secret into a number of reed solomon error correcting blocks (where n blocks are sufficient to recover the full data), is that fundamentally different?
With Shamir's secret sharing, having anything less than the required number of files is useless, you can't decrypt any of the data unless you reach the required number.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80....
where the authors explicitly write: "Shamir's scheme for sharing secrets is closely related to Reed-Solomon coding schemes."
now, my eyes glaze over when it comes to the math, so I'll need to look it through a few times before I understand what they are saying.
You can combine the reconstruction properties of Reed Solomon (you need k of n pieces) with the All or Nothing Transform. Encrypting data so that you need all of the data to decrypt.
Then you can essentially do Shamir secret sharing witout storage overhead. A 1 MB file split so you need 5 pieces would have 200 KB pieces instead of 1mb pieces. This is at a cost of exchanging information theoretic security for computational security.
Even the par2 format will let you do what you want here. Just toss out the original input data and give people 1/k the correct amount of parity blocks. Given a large enough file size [1], there is a vanishing probability that you can recover additional bits of the input with fewer blocks than needed. This also allows you to transmit less bits total (each target gets 1/k as many bits).
Of course, if you don't like this argument, you can always just encrypt the par2 blocks and use Shamir to share the key. This reduces the overhead to a multiple of the (hopefully much-shorter) key. EDIT: Commentary further down the thread indicates that a better idea is just to use an all-or-nothing transform.
[1] We have information theoretical security in the sense than you can't recover n bytes from (k-1)n/k bytes, so what I'm saying is that we need large enough n/k.
Looks good. I always try to build redundancy into my offline backups, as if the given backup in my hand is the last backup that hasn't been cooked / melted / flooded etc. ...because one day, it just might! Talking about worst-worst-case scenario, with triple redundancy of online-offsite (can be ransomwared), offline-onsite (can be flooded/burned), and online-onsite (1st line of defense, ie syncthing or a nas)
For some reason, my gut was telling me each piece would be smaller than the original.
I wonder if this (horcruxes of size ~ 1/N) is actually possible.
If your data is compressible, you should do that first.
In particular, consider your example (5 horcruxes with 3 needed to reconstruct). View the original file as the interval (0, N) and view it as a set covering problem. If each horcrux covers an interval of size N/3, then if any pair overlaps, there is no third horcrux that can complete the covering. This is a contradiction because 5 horcruxes of size N/3 must overlap somewhere.
RAID 6 uses some linear algebra to allow m of n copies to reconstruct the original data, where typically m = n - 2, but the math works for any number you like. So if you split up the data using the exact same algorithm, and pre- or post-encrypt the blocks, you should get the same thing being attempted here, and only inflate storage by n/m
The backstory on this was me freaking out when I had a newborn coming and I wanted my legacy to be handed to him at the right age if something happened to me.