RE: [oic] encryption of signature files

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

The known plaintext attack I have in mind is like the directory-visibility
one on steroids.  The visibility of the manifest, along with the fact of
encryption, may be very useful in deciding that a given file is a likely
document of interest.  That the files are individually encrypted, all with
the same user-supplied key, is what makes the attack so promising, as in the
case Rob mentions.

The fact that a hash of (part of) the unencrypted but compressed file is
stored with the encryption parameters provides a way to (1) discover whether
there is a known plaintext having the same compressed-file hash to either
completely subvert the encryption or (2) be used to attack the user-supplied
key and thereby decrypt other files in the same package that don't have a
known plaintext.

In the case of the SHA1/1k hash, I'll wager there may be many files lying
around in unencrypted ODF packages that have that same hash for their first
1k of compressed bytes.

This combined with the likelihood that the attacker can take lots of time to
attack a document that is considered prized but not intensely time-sensitive
would make me very nervous about using ODF Package Encryption for anything
very sensitive (not that I have anything like that lying around).

There are steps that an ODF package producer can take to ensure that even
the same XML part in two different packages is unlikely to have the same
initial compression blocks and therefore not have a common SHA1/1k hash.
That's not foolproof because non-XML package files may not be so amenable to
noise injection.

The safest approach I can see, in addition to up-front and periodic noise
injection to raise the entropy of compressed XML files, is to (1) permute
the blocks of the Zip file so that there are no predictable block positions
and (2) encrypt the entire permuted zip, with the permutation information
conveyed along with the encryption parameters in a PKI-encrypted envelope
and wrapper.  

The PKI approach is particularly nice when key exchange is not required.
When secure key exchange is required, that's an invariant concern across all
of these approaches.  Having the exchange use a binary cryptographic key
that cannot be attacked the same way as an user-typable plaintext pass
phrase remains an advantage.

 - Dennis



-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Friday, December 11, 2009 14:54
To: oic@lists.oasis-open.org
Subject: Re: [oic] encryption of signature files

I'm not certain what Dennis is referring to, but it might be the 
known-text attack on ZIP files that has been known for 15 years or so. 
Essentially, the table of contents for the ZIP file readable by anyone, so 
if you can look at the names of the files in the ZIP and correctly guess a 
portion of the plain text in one of those files, you can reduce the cost 
of a brute force attack to determine the encryption key.  The more bits 
you can guess in the plain text, the easier it will be to recover the key. 
 

-Rob


Hanssens Bart <Bart.Hanssens@fedict.be> wrote on 12/11/2009 01:06:20 PM:


> 
> > I have a pent-up pending analysis and blog post on the ODF 1.x package
> > encryption scheme's vulnerability to known-plaintext attacks.  Thefact 
that
> > the digital signature files cannot be encrypted is also something that
> > should raise eyebrows in document security circles.
> 
> Hmz, probably I'm missing something here, but I haven't read that one 
cannot
> encrypt the signature files (or other files in META-INF, except the 
> manifest.xml)
> 
> As far as I know, one cannot encrypt the manifest (otherwise it'll be a 
tad
> difficult to get to the encryption/decryption parameters), nor the 
mimetype
> stream...
> 
> Part 3 mentions that, for encrypted documents, Thumbnails/thumbnail.png
> may be a dummy one (but I haven't seen a statement that one isn't allow 
to
> simply encrypt that one as well, although that might cause some trouble 
for
> environments trying to show the preview, so probably not a good idea)
> 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php