[1776] in cryptography@c2.net mail archive
Re: Marutukku - cryptographic filing system
daemon@ATHENA.MIT.EDU (proff@iq.org)
Tue Oct 28 14:34:30 1997
From: proff@iq.org
Delivered-To: proff@iq.org
In-Reply-To: <199710281829.LAA06326@nyx10.nyx.net> from Colin Plumb at "Oct 28, 97 11:29:07 am"
To: colin@nyx.net (Colin Plumb)
Date: Wed, 29 Oct 1997 06:27:11 +1100 (EST)
Cc: proff@iq.org
> for it) yet, but I notice that your encryption does not hide the location
> of small changes to a block. Might this be a vulnerability in some
> applications?
I can only see one potential vulnerability. Magnetic/domain analysis
of the disk substrate could reveal these locations. This isn't a
known plain text issue (because the ufs super-block ensures there
is known plain text, and one can take for grantred a lot of null
padding by the file-system). Given the generation system I'm
using to generate fs-block keys, targeting the fs-block with the
information you want becomes quite important (although if there
are a million fs-blocks in the maru "partition" then presumably
decrypting all one million blocks is only a million times harder
than decrypting one, and on the scales we are using, a million is
a small number (though of course inter-fs-block correlation isn't
going to help you in any normal sense)).
It's also possible that observing which parts of which fs-blocks
were written when (based on extracting previous writes using stm
techniques, or just looking at relative magnetic dissipation over
time) could give you confirmation as to particular type of information
being present (judged by the way it has changed over time) or not.
I think this point is valid. I originally had a PCBC style chaining
system for similar reasons, but scrapped it because of error recovery
concerns i.e a one bit error trashes 2k of data, and in my view if
the data is important enough to keep encrypted, then it is probably
important enough to not be currupted by a single bit error. OTOH
if the data really is important then you want to be able to tell
when even single bit errors occur so you can bring in the backup
(you did remember to make backups didn't you?:) . Done the right
way error amplfication can give you error detection, and I can
forsee a rather nice scheme based on this to hot-swap currupted
information between two mirror cipher text regions on different
spindles.
> In general, you don't want to re-use a (key,IV) pair, i.e. encrypt two
> messages with the same key and IV. Each time you write to a disk block,
> that is a new messge that should be encrypted differently from previous
> messages.
>
> Yes, it's a hard problem to solve. I've solved it by using a checksum
> of the plaintext for the IV, but you may have different ideas.
> --
> -Colin
I think this idea has merit. Thanks for the feedback.
--
Prof. Julian Assange |"Don't worry about people stealing your ideas. If your
| Ideas are any good, you'll have to ram them down
proff@iq.org | people's throats."
proff@gnu.ai.mit.edu | -- Howard Aiken
