data under one key, was Re: analysis and implementation of LRW

[Leichter, Jerry]

| > Currently I'm dealing 
| > with very large - though not as large as 4 gig - x-ray, MRI, and 
| > similar files that have to be protected for the lifespan of the 
| > person, which could be 70+ years after the medical record is 
| > created. Think of the MRI of a kid to scan for some condition 
| > that may be genetic in origin and has to be monitored and 
| > compared with more recent results their whole life.
| 
| That's longer than computers have been available, and also longer
| than modern cryptography has existed.  The only way I would propose
| to be able to stay secure that long is either:
| 1) use a random key as large as the plaintext (one-time-pad)
...thus illustrating once again both the allure and the uselessness (in
almost all situations) of one-time pads.  Consider:  I have 4 GB of
data that must remain secure.  I'm afraid it may leak out.  So I
generate 4 GB of random bits, XOR them, and now have 4 GB of data
that's fully secure.  I can release it to the world.  The only
problem is ... what do I do with this 4 GB of random pad?  I need
to store *it* securely.  But if I can do that ... why couldn't I
store the 4 GB of original data security to begin with?

*At most*, if I use different, but as secure as I can make them,
methods for storing *both* 4 GB datasets, then someone would have to
get *both* to make any sense of the data.  In effect, I've broken my
secret into two shares, and only someone who can get both can read it.
I can break it into more shares if I want to - though if I want
information-theoretic security (presumably the goal here, since I'm
worried about future attacks against any technique that relies on
something weaker) each share will end up being the same size as
the data.

Of course, the same argument can be made for *any* cryptographic
technique!  The difference is that it seems somewhat easier to protect
a 128-bit key (or some other reasonable length anything beyond 256 is
just silly due to fundamental limits on computation:  At 256 bits, either
there is an analytic attack - which is just as likely at 2560 bits, or
running the entire universe as computer to do brute force attacks won't
give you the answer soon enough to matter) than a 4 GB one.  It's not
easy to make really solid sense of such a comparison, however, as our
ability to store more and more data in less and less space continues
for a couple of generations more.  When CD's first came out, 600 MB
seemed like more than anyone could imagine using as raw data.  These
days, that's not enough RAM to make a reasonable PC.

I would suggest that we look at how such data has traditionally been
kept safe.  We have thousands of years of experience in maintaining
physical security.  That's what we rely on to protect the *last* 70
years worth of X-ray plates.  In fact, the security on those is pretty
poor - up until a short while ago, when this stuff started to be digital
"from birth", at least the last couple of year's worth of X-rays were
sitting in a room in the basement of the hospital.  The room was
certainly locked, but it was hardly a bank vault.  Granted, in digital
form, this stuff is much easier to search, copy, etc. - but I doubt
that a determined individual would really have much trouble getting
copies of most people's medical records.  If nothing else, the combination
of strict hierarchies in hospitals - where the doctor is at the top -
with the genuine need to deal with emergencies makes social engineering
particularly easy.

Anyway ... while the question "how can we keep information secure for
70 years" has some theoretical interest, we have enough trouble knowing
how to keep digital information *accessible* for even 20 years that it's
hard to know where to reasonably start.  In fact, if you really want to
be sure those X-rays will be readable in 70 years, you're probably best
off today putting them on microfiche or using some similar technology.
Then put the 'fiche in a vault....

							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com