https://issues.apache.org/ooo/show_bug.cgi?id=119090
--- Comment #16 from orcmid <[email protected]> 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.
