You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the program appears to copy the encrypted file into each horcrux, which becomes pretty storage intensive with a larger file and more horcruxes.
n is the number of horcruxes, t the number needed to ressurect, s is size of the file, t ≤ n
Reed-solomon encoding can split the original file into n pieces, each piece has a size of s/t. Any combination of t pieces can be used to recreate the original file.
So the total space used by the horcruxes would be n*(s/t) instead of n*s.
This should also ensure the integrity of the data as the reconstruction of the file should fail if a piece is modified.
The text was updated successfully, but these errors were encountered:
The current implementation of the program appears to copy the encrypted file into each horcrux, which becomes pretty storage intensive with a larger file and more horcruxes.
n is the number of horcruxes, t the number needed to ressurect, s is size of the file, t ≤ n
Reed-solomon encoding can split the original file into n pieces, each piece has a size of s/t. Any combination of t pieces can be used to recreate the original file.
So the total space used by the horcruxes would be n*(s/t) instead of n*s.
This should also ensure the integrity of the data as the reconstruction of the file should fail if a piece is modified.
The text was updated successfully, but these errors were encountered: