In article <e2**********@c anopus.cc.umani toba.ca>,
ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:
In article <e2*********@ne ws2.newsguy.com >,
Michael Wojcik <mw*****@newsgu y.com> wrote:
[OT]
An SD filesystem could include
filesystem metadata in such a way that for a given message, there
might exist a key which produced that message plus metadata that
meant "read only" to the filesystem, but no key shorter than the
message itself which produced the message plus "read/write" metadata,
so in effect the file could only be opened read-only.
I don't see where the restriction to "no key shorter" would come in,
nor the relevance of that length to "in effect" make the file read-only?
I just wanted to specify a stronger condition. Filesystems are a
compression mechanism: they let you substitute a shorter message
(the location of the file) for a longer one (the file itself). In
specific instances, the file may be shorter than the message that
specifies its location, but in general this holds for a majority
of cases. Consequently, I was indicating that it didn't matter if
there was a key longer than the message that didn't satisfy the
condition for read-only access.
Put another way, if the necessary key is larger than the file, you
might as well just carry around the file, and forget about the
filesystem entirely, so that case isn't interesting. And since
typical SD designs let you create any message no longer than the size
of the filesystem, by finding a suitable key, it's possible that the
implementation would reject any key over a certain size, on the
grounds that "real" keys used in practice would be kept to a
managable length. (The deniability aspect can be maintained to a
sufficient level to meet a given threat model even in this case by
setting the maximum key length high enough, provided the threat model
doesn't require absolute deniability.)
On reflection, though, this may not be an interesting distinction.
For one thing, the compression function of a filesystem is really the
mapping between the location of the file and the pair consisting of
the set of all possible valid messages contained in that file and
the index of the current message.
It's since occurred to me that a more relevant issue is what the
distinction between "read-only" and "writable" means in this context.
For example, does writable imply readable? If not, how is write-
only access implemented? (This is a different question from a
possible implementation of stdio, since the latter could simply
ignore readability when opening write-only.)
In practice, a more suitable way of imposing write protection for an
SD filesystem would probably be to keep file verifiers separately, so
they can't be captured as part of the filesystem and used to defeat
deniability.
Oh well. This is really a sci.crypt topic, and to be honest just
something I keep an idle eye on, so I might be talking complete
rubbish about the possibility of imposing access restrictions in a
case like this.
--
Michael Wojcik
mi************@ microfocus.com
I do not care to listen; obloquy injures my self-esteem and I am
skeptical of praise. -- Jack Vance
