Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

From a quick investigation, enlightened by the note referenced by @librebel, the hope to recover your file is next to nothing.

An .odt file is in fact a zipped directory (change extension odt to zip and you'll be able to decompress it). In this directory, file META-INF/manifest.xml describes all other components in a <manifest:manifest> XML element with nexted <manifest:file-entry> elements.

When a file is password protected, the file-entry element contains a <manifest:encryption-data> elements with subelements giving details on how this file was encrypted.

To improve protection against cryptanalysis, the file is zlib-deflated (to reduce entropy) before being encrypted. This means that instead of having fixed prefix of <?xml version="1.0" encoding="UTF-8"?> + Return, we have a much shorter run of bytes (of which the last is not reliable because some bits can be used for what follows) against which to test our guesses.

The password provided is first mangled through a process names key derivation so that the bits are made more random than printable characters and the resulting key is 32 bytes = 256 bits long. Such a length is not in the cracking reach of poor amateurs like ourselves. To complicate matters, the salt, i.e. an initial value for some register, is different for each file, meaning any knowledge we may have gained on a particular file is of no use on the next file.

The <manifest:key-derivation> element tells us that 100000 (yes 100k) iterations are made before obtaining the key; with as many iterations, bits in the key are no longer visually related in any means to the human password.

Once this key is manufactured, it is used in the AES-256 with CBC mode with a random initialisation vector specific to each file. The fact that the initialisation vector is explicitly given in the element does not help much.

Worse, I made a test to see how these data were "permanent": they change every time you save your file. It is likely that both salts and initialisation vectors include some form of save operation time-and-date.

The morale of the story is you can't hope to break the encryption because strong cryptography is used here. Brute force will do nothing: supposing we can make one test every millisecond, compute how long are 2^256 milliseconds (there are 86400 seconds in a day, rounded to 100000=10^5, 2^256 rounded to 10^85; that makes 10^78 seconds and 10^9 seconds is roughly 30 years).

Since password protection offers the possibility to protect a file, yet make it possible to share it with another password, this meant for me that both passwords would hide the real key stored somewhere in the file. You encrypt with only one key, therefore having two access passwords needs an intermediate step to grasp the key, the software then makes a difference in what you are allowed to do from the access password.

Alas, I saw nowhere any lead towards this kind of feature. Absolutely all subfiles are encrypted, there is thus "supra-backdoor" to the content. For the record, I am no developer and I must make my guesses from a file example not from source code (which is by the way so huge, I can't grasp the gist of it in minutes). However, I'm quite confident in my guesses.

Conclusion: try to remember your password. In order to do that, don't think about it. Go for a walk, practise some sport, play music, do other activities that decency forbids to mention here, anything, so that your mind relaxes.

From a quick investigation, enlightened by the note referenced by @librebel, the hope to recover your file with cryptanalysis is next to nothing.nothing. @Lupp's idea may be one of the best alternatives.

An .odt file is in fact a zipped directory (change extension odt to zip and you'll be able to decompress it). In this directory, file META-INF/manifest.xml describes all other components in a <manifest:manifest> XML element with nexted <manifest:file-entry> elements.

When a file is password protected, the file-entry element contains a <manifest:encryption-data> elements with subelements giving details on how this file was encrypted.

To improve protection against cryptanalysis, the file is zlib-deflated (to reduce entropy) before being encrypted. This means that instead of having fixed prefix of <?xml version="1.0" encoding="UTF-8"?> + Return, we have a much shorter run of bytes (of which the last is not reliable because some bits can be used for what follows) against which to test our guesses.

The password provided is first mangled through a process names key derivation so that the bits are made more random than printable characters and the resulting key is 32 bytes = 256 bits long. Such a length is not in the cracking reach of poor amateurs like ourselves. To complicate matters, the salt, i.e. an initial value for some register, is different for each file, meaning any knowledge we may have gained on a particular file is of no use on the next file.

The <manifest:key-derivation> element tells us that 100000 (yes 100k) iterations are made before obtaining the key; with as many iterations, bits in the key are no longer visually related in any means to the human password.

Once this key is manufactured, it is used in the AES-256 with CBC mode with a random initialisation vector specific to each file. The fact that the initialisation vector is explicitly given in the element does not help much.

Worse, I made a test to see how these data were "permanent": they change every time you save your file. It is likely that both salts and initialisation vectors include some form of save operation time-and-date.

The morale of the story is you can't hope to break the encryption because strong cryptography is used here. Brute force will do nothing: supposing we can make one test every millisecond, compute how long are 2^256 milliseconds (there are 86400 seconds in a day, rounded to 100000=10^5, 2^256 rounded to 10^85; that makes 10^78 seconds and 10^9 seconds is roughly 30 years).

Since password protection offers the possibility to protect a file, yet make it possible to share it with another password, this meant for me that both passwords would hide the real key stored somewhere in the file. You encrypt with only one key, therefore having two access passwords needs an intermediate step to grasp the key, the software then makes a difference in what you are allowed to do from the access password.

Alas, I saw nowhere any lead towards this kind of feature. Absolutely all subfiles are encrypted, there is thus "supra-backdoor" to the content. For the record, I am no developer and I must make my guesses from a file example not from source code (which is by the way so huge, I can't grasp the gist of it in minutes). However, I'm quite confident in my guesses.

Conclusion: try to remember your password. In order to do that, don't think about it. Go for a walk, practise some sport, play music, do other activities that decency forbids to mention here, anything, so that your mind relaxes.

From a quick investigation, enlightened by the note referenced by @librebel, the hope to recover your file with cryptanalysis is next to nothing. @Lupp's idea may be one of the best alternatives.

An .odt file is in fact a zipped directory (change extension odt to zip and you'll be able to decompress it). In this directory, file META-INF/manifest.xml describes all other components in a <manifest:manifest> XML element with nexted nested <manifest:file-entry> elements.

When a file is password protected, the file-entry element contains a <manifest:encryption-data> elements with subelements giving details on how this file was encrypted.

To improve protection against cryptanalysis, the file is zlib-deflated (to reduce entropy) before being encrypted. This means that instead of having fixed prefix of <?xml version="1.0" encoding="UTF-8"?> + Return, we have a much shorter run of bytes (of which the last is not reliable because some bits can be used for what follows) against which to test our guesses.

The password provided is first mangled through a process names key derivation so that the bits are made more random than printable characters and the resulting key is 32 bytes = 256 bits long. Such a length is not in the cracking reach of poor amateurs like ourselves. To complicate matters, the salt, i.e. an initial value for some register, is different for each file, meaning any knowledge we may have gained on a particular file is of no use on the next file.

The <manifest:key-derivation> element tells us that 100000 (yes 100k) iterations are made before obtaining the key; with as many iterations, bits in the key are no longer visually related in any means to the human password.

Once this key is manufactured, it is used in the AES-256 with CBC mode with a random initialisation vector specific to each file. The fact that the initialisation vector is explicitly given in the element does not help much.

Worse, I made a test to see how these data were "permanent": they change every time you save your file. It is likely that both salts and initialisation vectors include some form of save operation time-and-date.

The morale of the story is you can't hope to break the encryption because strong cryptography is used here. Brute force will do nothing: supposing we can make one test every millisecond, compute how long are 2^256 milliseconds (there are 86400 seconds in a day, rounded to 100000=10^5, 2^256 rounded to 10^85; that makes 10^78 seconds and 10^9 seconds is roughly 30 years).

Since password protection offers the possibility to protect a file, yet make it possible to share it with another password, this meant for me that both passwords would hide the real key stored somewhere in the file. You encrypt with only one key, therefore having two access passwords needs an intermediate step to grasp the key, the software then makes a difference in what you are allowed to do from the access password.

Alas, I saw nowhere any lead towards this kind of feature. Absolutely all subfiles are encrypted, there is thus no "supra-backdoor" to the content. For the record, I am no developer and I must make my guesses from a file example not from source code (which is by the way so huge, I can't grasp the gist of it in minutes). However, I'm quite confident in my guesses.

Conclusion: try to remember your password. In order to do that, don't think about it. Go for a walk, practise some sport, play music, do other activities that decency forbids to mention here, anything, so that your mind relaxes.