On Mon, 2004-12-06 at 09:57, Jim Fenton wrote:
Douglas Otis wrote:
The MSTATE header information provides two things. It tells you the
original length as well as a simple hash value of the header or data
section. Analysis could make simple guesses as to the original
information, and confirm this with the simple hash. Once the header or
message part has been restored or removed, the signature is rechecked.
This process only succeeds when the signature validates.
This (last sentence) is the essential piece that I was missing. Unless
the recipient is able to reconstruct a message that validates correctly,
all bets are off; nothing in the message can be used reliably. This
wasn't clear to me from your earlier description.
It seems like a lot of trial and error may be required, with
recalculation of the signature at each step. Correct?
Framing of data with Reed-Solomon parity fields, commonly used to
protect tape and optical channels (developed by JPL to handle the
sporadic pulsar deletions from satellite channels), could be applied to
this problem by allocating a fixed amount for each header and data
partition and adding a few additional parity fields, but that would be
over kill. This code does exist within the public domain and has
relatively low overhead. : )
I suspect this would be considered overly complex however, so something
much simpler to implement was the MSTATE header.
In the event of a signature failure, the concept of the MSTATE header
was to permit a diagnostic utility that would analyze this failure to
indicate what changed as a tool for initial deployment. By creating a
template, even if the signature could not be restored, knowing why would
be useful. Even more useful would be to consider any affects that did
not delete the content of a message not guessable and munged by way of
somewhat predictable changes. With this assumption, the use of the hash
value together with the length would allow quick confirmation in search
for exactly what changed. The signature would not be applied at each
step but only as a final confirmation. That was the reason for the
hash. I would be happy to create a more complete draft for this
concept.
As this would be a generalized template of the original message, the
sender would not need to anticipate what might change. Regardless of
the channel signature method (IIM, DK, etc) this header information
could be applied and, over time, the analysis software could improve on
its iterations in attempt to restore the message signature. This
technique could advise the MDA that only information confirmed via the
signature be retained. Perhaps an analysis header could enclose this
discovered excess baggage.
In my early days of developing tape, disk, and optical drives, simply
flagging errors was considered an acceptable practice. This field has
matured and does not accept that somewhat naive approach any longer. To
get this signature business safely off the ground, some diagnostic tool
would be useful. I would suspect that within half a decade, this tool
would longer be needed. Think this header as a type of training wheels.
-Doug