incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 119090] Default Encryption Fails for Down-Level Implementations
Date Fri, 23 Mar 2012 01:31:32 GMT
https://issues.apache.org/ooo/show_bug.cgi?id=119090

--- Comment #16 from orcmid <orcmid@apache.org> 2012-03-23 01:31:32 UTC ---
(In reply to comment #9)
> Dennis, IIRC, some of your attacks require access to something like 1 trillion
> different test documents encrypted with the same password.
> So, I'm not persuaded that the attack points you mention are weaker than
> Blowfish itself. If they are not,then the move to AES still increases security.

Rob, I didn't want to reply to this, because it is a kind of red herring. 
However, others may assume this is a serious fact.

I have never considered anything that requires finding multiple documents
encrypted with the same password, nor creation of multiple test documents
encrypted with the same password.  

I have only considered attacks on a single document signed by the password of
someone who wants that document to be a secret known only to those with whom
the password has been shared by some means.  (The common case is when a
document is encrypted to keep it private and only one person knows the
password.)

There is an opportunistic attack available if any of the parties have used that
same password in other ways where the password or its SHA1 hash or its SHA256
hash has become known.   For example, in the case of ODF documents, if the same
password has been used to set protections on unencrypted documents that is used
to encrypt some documents, the protection keys formed with that reused password
become available to attack the encrypted document.  In this case, one simply
wants to collect documents by the same parties that are likely or known to have
protections set.  The fact that protection key digests and encryption start-key
digests are not salted, makes this trivial, although the opportunity can't be
counted on.

Nevertheless, you may recall that I have proposed updates to the ODF 1.3
specification (and ODF 1.2 extended documents) that remedy this specific case
and the exposure of passwords via their known unsalted digest values.  These
documents are available to the public via
http://tools.oasis-open.org/issues/browse/OFFICE-3709 and
http://tools.oasis-open.org/issues/browse/OFFICE-3703

More practically, there are features of ODF documents that facilitate attack on
the password directly.  Note that an attack on the password is independent of
whether Blowfish or AES 256 are used for the actual encryption.  (In fact, it
may be easier in the case of AES256-cbc, since Blowfish with 8-bit CFB may be
slower to encrypt and decrypt with.)  The key used by the encryption itself is
derived from the password and is intended to be unique for each encryption ever
done with that password.  However, if the password is known, the encryption
key, whether for Blowfish or AES, is determined exactly.

The first curious feature is the fact that encrypted ODF documents include a
plain-sight digest value of the first 1k bytes of each unencrypted (but
compressed) file inside the ODF Zip package.  This is used to determine whether
or not the decryption is working correctly for that file (i.e., the password
can be presumed to be successful).  This is just as useful to an attacker as it
is to ODF consumers that have been given a password to try, of course.

The second feature is the fact that there are gratuitously-included
known-plaintext files in every ODF package produced by the well-known
OpenOffice lineage implementations. Some of these are relatively short and
their sizes and compressed values are known in advance.  That makes these files
easy to spot in an encrypted ODF package.  That makes them interesting as aids
to discovery of the password (or its digest) as well.  (It may even be the
case, because of the extensive use of boilerplate on the front of some ODF XML
parts, that the first 1k bytes of their compressions become known plaintext
too.)

Finally, these are persistent documents, not streams occuring in one-time
data-exchange with limited time sensitivity.  That means all of this attacking
can be done off-line, even crowd-sourced.  In particular, a precomputed
dictionary of SHA1/SHA256 digests of likely passwords is promising.  Because
the known plaintext content is benign (it is insignificant boilerplate in most
cases), a criminal-enterprise cracking service need not be shown the ODF
Package for which the password needs to be discovered.  Only the known
plaintext part and the encryption of its compressed form needs to be shared,
along with the non-secret encryption parameters.  The discovered password (or
its digest) can then be used to decrypt the entire document.

None of this requires cracking of Blowfish or AES, but some wicked fast
Blowfish and AES implementations are important for the attacker to be able to
use as tools.

Now, just as there are ways to deflect attacks by salting digests and not using
the same scheme for start-keys as anywhere else, it is also possible to
eliminate the availability of gratuitous known plaintexts.  The first approach
is not to produce them if they have no actual purpose for the document at hand.
 And if that can't be avoided, there are ways of arranging that known-plaintext
XML documents not have known compressed files, making the encryption of that
compressed file not of an already known compressed plaintext.  This is
accomplished by introducing chaff into the the XML documents before they are
compressed and subseqently encrypted.  The chaff can be random and designed in
a way where it does not interfere with the processing of the decrypted and
decompressed file.  This means that even if it is known what the
unchaffed-plaintext is likely to be, that is no help in figuring out how to
crack the encrypted version.  Now attack on the password is not so good
(although the plain-sight digest values are still useful).  [I am indebted to
Caolin McNamara for suggesting that random but benign insertions be termed
"chaff."]  Note that this technique doesn't work for all kinds of content, and
if there is a recuring image, for example, found in both unencrypted and
encrypted documents from the same source, the known plaintext condition is
still satisfied.

 - [whew]

-- 
Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Mime
View raw message