This bug can result in loss of data if one opens an older password-protected spreadsheet (*.sxc format), makes some changes, then clicks on "save" (it will overwrite original file, and both the original data and modifications will be lost because one will no longer be able to open the encrypted file despite knowing the correct password). Changing importance to "High/Major".

Just checked and bug also happens with text files (saving password-protected *.sxw = openoffice 1.0 text file type).

Modifying subcomponent from spreadsheet to libreoffice (this is more general bug not particularly related to spreadsheet code). Cannot yet determine specific libreoffice component involved (legacy export filter? encryption?).

Just reporting additional finding that may or may not be relevant to this issue:

Besides the problem regarding the legacy Openoffice 1.0 formats, backward compatibility is broken for files saved with a password from LO 3.4.5, LO 3.4.6 and 3.5.1 in current ODF format (e.g. *.ods files for example), which can be open fine (with the password) in the newest releases of LO (3.4.5, 3.4.6 and 3.5.1) but NOT in earlier versions of LO 3.4.x, LO 3.3.x or Openoffice (tested 3.3.0). The following error message appears in a pop-up dialog:

Read-Error.
Format error discovered in the file in sub-document content.xml at 1.0(row,col).
OK

So something important has changed from LO 3.4.5 on in the way the ODF and OO files are saved encrypted with a password, which result in (1) loss of backward compatibility of the saved encrypted files with earlier versions of LO; (2) loss of data if one inadvertently saves current work ONLY in the OO 1.0 format with a password (after closing the file data are lost forever because saved file cannot be open either with the newer 3.4.5 and later LO versions or older versions of LO or OO.org).

Further investigating this issue in the issues "solved" in 3.4.5, I found some interesting bug reports ("closed") including:

https://bugs.freedesktop.org/show_bug.cgi?id=43868

https://bugs.freedesktop.org/show_bug.cgi?id=40006

Most interesting is comment 7 from the later:

https://bugs.freedesktop.org/show_bug.cgi?id=40006#c7

I've tested it and found a workaround to current issue:

1. Launch LO 3.5.1 (or 3.4.5/3.4.6)
2. Tools -> Options -> Load/Save -> General -> ODF Format version -> (change to 1.0/1.1)
3. Open password-protected Openoffice 1.0 spreadsheet created in previous versions of LO 3.x or OpenOffice 3.x, or create a brand new one (with a password).
4. Modify some data
5. Click on save icon (or File -> Save)

File is now saved (not prompting for the previously established password).

6. Close file
7. Try to open the file from any version of LO 3.x or OO 3.x.

It now opens fine with the correct password.

In summary:

1. A decision has been made by the developers to change encryption algorithm (to AES?) which explicitly makes files saved with a password from 3.4.5 and later versions of LO incompatible with older versions of LO or OO.org.

2. A workaround has been previously suggested (but apparently not included in the Release Notes or "Known Issues" - Developers, could you do this?) to change ODF version from 1.2 Extended (recommended) to 1.0/1.1 prior to saving ODF files or OO 1.0 files with a password to make them backward compatible with older versions of LO (prior to 3.4.5) or OO.org

3. Openoffice 1.0 export filters in 3.4.5, 3.4.6 and 3.5.1 are "unaware" of the update and save the encrypted file with newer encryption method (AES?) but older ODF format (1.0/1.1 ?!) making FILEOPEN impossible for ANY version of LO or OO...

Hope this additional enables this bug to be included in the "easy tasks" list... (just kidding?).

BTW - I'm NOT a developer, please HELP!!!!

Actually LO 3.4.5 and 3.4.6 behave correctly by using SHA1/1K and BlowFish CFB when saving an encrypted ODF file in legacy format (Openoffice 1.0 *.sxc or *.sxw) as is evident by examining the corresponding manifest.xml.

However LO 3.5.1 uses SHA256-1k and AES256-cbc to create the password-protected file with the legacy file types, and at the same time is unable to decrypt the very file it just created and encrypted with the newer method. So it behaves in a way that is neither backward-compatible (which would be desirable when saving in "legacy" formats intended to be opened by older versions of OO.org, or when re-saving older files originally created in the past and in use for several months or years without difficulties) nor compatible with the decryption capabilities of the newest LO versions (3.4.5, 3.4.6) besides the very one that created the "locked forever" file...

Is there a reliable way to manually decrypt content.xml or the remaining encrypted data from these "corrupted" files? Has LO 3.5.1 actually used the user-provided password to encrypt in a way that cannot be decrypted by the program, or has it actually corrupted the password? If the first is true, then does the program makes some "assumptions" as to the decryption method that should be used for opening these "legacy" formats that prevent it from using the appropriate AES256 / SHA256 methods when trying to reopen the file? Does someone know a way to manually recover the content of these malformed files by typing the correct command line code (e.g. using "openssl enc -d" or something similar, and how to easily obtain the "hex" version of the salt and of the initialization vector, and whatever else is required for successfully recovering them)?

Also reproducible in LO 3.5.2.2
(ID 281b639-6baa1d3-ef66a77-d866f25-f36d45f )

1. New spreadsheet
2. Save as -> Openoffice 1.0 spreadsheet (save with password)
3. Type in password
4. Close file
5. Try to open same file in LO 3.5.2.2 (type same password used to save the file in step 3) -> fails with error message "the password is incorrect. File cannot be opened".

By inspecting manifest.xml of the *.sxc file created by LO 3.5.2.2 we can see it has used (or supposedly used) the newer encryption method (AES256-cbc / sha256-1k).

Switching ODF version from 1.2 extended to 1.0 (in options -. Load/Save) "fixes" the issue. However now ALL files use older ODF spec (even otherwise up-to-date file formats) and "Not using 1.2 extended ODF format can lead to information loss"...

Possible fix:

Make export filters (?) automatically use SHA1-1K + BLowfish encryption method and/or temporarily switch to ODF Format version 1.0 when saving current file (text/spreadsheet/others?) as openoffice 1.0 format...

[=> Less optimal - "teach" LO 3.5.x how to decrypt the "aberrant" openoffice 1.0 files (???) which cannot be opened by LO 3.4.x nor by ApacheOO 3.4.x too (just tested !).]

This bug is still present as of 3.6.2.2 (Build ID: 360m1(Build:2)), the standard version of LibreOffice that currently ships with Ubuntu 12.10.

I just lost a bunch of files. Please note that this bug affects the SXC format, and it applies to files saved "with password", and then opened with the *same* version of LibreOffice. This is what the original bug description said. Some of the comments above seem to refer to a different bug.

To reproduce:

* Create a new spreadsheet in LibreOffice
* Type "abc" into A1
* File -> Save As. Select "OpenOffice 1.0 Spreadsheet (.sxc) as the file format. Select "Save with password". Type a filename and "Save".
* When prompted, type "test" as the password (and a second time to confirm).
* Close the file and quit LibreOffice.

* Start LibreOffice again. Open the file just saved. When prompted, enter "test" as the password. 
* You get the error message "The password is incorrect. The file cannot be opened."

An alternative way to reproduce this bug is:

* open an .sxc file saved "with password" with an older version of LibreOffice.
* when prompted, enter the password.
* the file will open with no problems.
* modify the file.
* save it (Ctrl-S).
* the file will save with no errors.
* close the file.
* open it again.
* when prompted, enter the correct password.
* error: "The password is incorrect. The file cannot be opened."

It is this latter method by which it is very easy to lose data, because an apparently saved file will overwrite the previous version, but will become unopenable.

Question: Why do I want to save files in the SXC format? Answer: I don't, really. I just have some spreadsheets that are up to 10 years old. At some time in the past, SXC was the "standard" format, and I just never changed it until now. 

Please, please fix this bug. It has been open for over a year, and it has not even been assigned to anyone. Thanks, -- Peter

Still reproducible in the latest release (4.0.3.3):

1. Create new spreadsheet with LibreOffice Calc;
2. Save it with password as Openoffice 1.0 (*.sxc) Spreadsheet;
3. Close file;
4. Try to reopen saved file;

Expected behavior: After typing correct password the file is opened by LibreOffice;

Observed behavior: Cannot open file ("wrong password" error even though the same password used to create/save the file is used when trying to open it).

Changing Importance to Medium/Normal since probably most users nowadays create files in the newer formats (.odt, .odc, and so on) instead of older OpenOffice 1.0 format (.sxw, .sxc, etc...). Anyway this issue may lead to the loss of data if an older existing password-protected file is opened, modified and then re-saved with current version of LibreOffice since the older file will be overwritten by the new one which can no longer be opened (with or without the correct password).

please can you at least add a message on opening password protected sxc's for editing so that it warns the user to save as an ods, or disable saving of sxc's with passwords.

Our lovely payroll lady just lost the staff salaries file after an upgrade to LO3.6 ... assuming that it was a one off she got a backup, made the changes again and lost them all again on saving.

I am flabbergasted that this bug has remain unfixed for so long, and further that its importance has been downgraded (I'm putting it up to highest/critical).  I can't think of a more critical fault than one that permanently(?) loses user's data, other than one that does so in more common circumstances.

Using L.O. 4.0.3.3. I have just lost two files because of this fault, and it seems that nobody cares.  As things stand, I certainly won't be recommending LibreOffice to anyone given that they care so little for users' data.

I have a few old password-protected .sxw files which I opened, edited, and resaved in the same format.  Now when I try opening them, I get "The password is incorrect. The file cannot be opened.", and the work-around given in comment 4 isn't working for me.  As I doubt any other existing bug has such critical consequences, it should be given the highest priority so that users with existing inaccessible files can open those files.

Created attachment 86764 [details]
SC1 spreadsheet [test]

I can open the saved spreadsheet both in OO 1.1 and 4.1.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=11ad93f4ba84f190c908e92a2c960f7a9fa800c0

Resolves: rhbz#1013844 fdo#47482 encrypted OOo 1.0 docs cannot be reopened



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f21ee4bd0d7b6082e8aa1a9f00ba467063fa5b27&h=libreoffice-4-1

Resolves: rhbz#1013844 fdo#47482 encrypted OOo 1.0 docs cannot be reopened


It will be available in LibreOffice 4.1.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac848787f90cf247fab29e98bc406b1237d14b84&h=libreoffice-4-0

Resolves: rhbz#1013844 fdo#47482 encrypted OOo 1.0 docs cannot be reopened


It will be available in LibreOffice 4.0.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-0-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=991632a54ec6dcc5390f276bdb453c8fa966a15b&h=libreoffice-4-0-6

Resolves: rhbz#1013844 fdo#47482 encrypted OOo 1.0 docs cannot be reopened


It will be available already in LibreOffice 4.0.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Thank you Caolan!

The fix works fine in most situations. I have done the following tests obtaining the following results (L.O. writer, Linux):

1. Opening a backup copy of the "corrupt" openoffice 1.0 file saved with password from L.O. 3.5.1:

With L.O. 3.6.6 (obsolete version I still have around): fails
With L.O. 4.0.6: works
With L.O. 4.1.3: works

2. Opening a new text file saved from L.O. 4.1.3 with password in OO 1.0 writer format:

With L.O. 3.6.6 (obsolete version): works
With L.O. 4.0.6: works
With L.O. 4.1.3: works

3. Opening a new text file saved from L.O. 4.0.6 with password in OO 1.0 writer format:

With L.O. 3.6.6 (obsolete version): fails.
With L.O. 4.0.6: works
With L.O. 4.1.3: works.

Thank you again.

The fix works for me too.  I was able to open the files that I couldn't open thanks to this bug.  Thanks Caolan; much appreciated.

*** Bug 76155 has been marked as a duplicate of this bug. ***