pull down to refresh
encode(data) = f decode(g) = datawhere f and g are not equal, but f and g are permutations of {1,2,3,4,...,M}.
What this makes me think of as someone specialized in security in CS is "second preimage" from hash functions. Let's do a quick transformation:
decode(g) = data <=> encode(decode(g)) = encode(data) <=> g = encode(data) => encode(data) = f encode(data) = g with f !=g
Functions that fulfill this property are insecure hashfunctions. Especially compressing hashfunction for which two preimages can easily be found (google "second preimage resistance"). I know this doesn't help you directly but maybe ths cryptographic perspective helps you searching
reply
Right, that is actually why I am trying to focus more on the error-correction aspect of this. Using a secure hash function for checksum calculation (as in the bip39 spec) helps determine that there is an error but it does not identify where the error is nor help correct it.
Reed-Solomon error correcting codes are more what I am seeking, but it is non-trivial to make those work for permutations.
Anyway, there seems to be less interest/activity in this bounty thread than I was anticipating, so I went ahead and awarded the bounty to you!
reply
data
(e.g. entropy for a cold wallet, which itself may include some of its own checksums, etc), and I want the whole thing to be represented as a permutation of{1,2,3,4,5...,M}
. So what I want is definitions forencode
anddecode
such that:f
andg
are not equal, butf
andg
are permutations of{1,2,3,4,...,M}
.f
by putting the cards in the order determined byf
and then destroying the underlying original entropy (the secret) since it is now represented byf
. Maybe Sender then buries this deck of cards in a hole in the ground or something :-).g
which is not equal tof
. In other words, there was an error in the transmission. However, all hope should not be lost.f
with enough error correction capabilities that even if the receiver receivesg
, the receiver can still find the underlying original secretdata
fromg
?