Sujet : Re: Memorizing a 128 bit / 256 bit hex key
De : rich (at) *nospam* example.invalid (Rich)
Groupes : sci.cryptDate : 18. Jun 2024, 20:42:08
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v4snug$1gjt3$1@dont-email.me>
References : 1 2 3
User-Agent : tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Stefan Claas <
pollux@tilde.club> wrote:
Rich wrote:
Given that the "dates" chunk the long string into "blocks", it might be
reasonable to use an erasure coding algorithm on the "blocks", and append
one or more blocks (i.e., dates) that are the erasure codes. Then
forgetting (or misremembering) one or two of the dates might still
allow for recovery of the original key (or at least allow for detection
of a misremembering situation).
Well, I guess this would then need a program to handle, right?
Yes, but you also need a program to handle the conversion from dates to
hex and back. Granted, few would suspect that the "date" command was
used to convert the dates back into a 'key'.
My Idea is to use no program for that, so that no evidence can be
found on the device, in case someone is looking at it.
It could be a generic erasure coding program, and the exact parameters
(block size, amount of redundancy, etc.) are remembered and specified
only when it is run to 'check' the output. Then it would, presumably,
be no more suspicious than the 'date' command itself (other than what
suspicion might be raised by the fact that most OS'es don't ship with
an erasure coder by default).