[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [libreoffice-users] FIPS 140-2 support with password-protected docs


On 04/01/2019 08:39, Heiko Tietze wrote:
Forwarding to the devloper list

[lets continue the discussion on the libreoffice@lists.freedesktop.org developer list]
-------- Weitergeleitete Nachricht --------
Betreff: [libreoffice-users] FIPS 140-2 support with password-protected docs
Datum: Thu, 3 Jan 2019 12:08:55 -0500
Von: Sean <smalder73@gmail.com>
An: users@global.libreoffice.org



Hi, I just joined the list. I'm a Linux system admin with (among
other things) about 20 CentOS 7.6 desktops under my wing. Yesterday I
posted a question to the ASK site [1], because one of my users had
issues with password-protected docs after getting his new laptop. I
now have confirmed that this issue is related to our desktops being
FIPS enabled ( kernel/grub2 with fips=1 ).

I joined the list to further this discussion and determine if I should
file a bug report or what. The gist of the problem is that when FIPS
is enabled, a user can encrypt a document, but not decrypt the
document, and LO reports that the password provided was incorrect. I
am not very technical with how LO does password protection, but this
seems like an bug. FIPS causes the system to disable non-compliant
ciphers and algorithms, but I'm guessing that there is some piece of
code that's calling a non-compliant function only on decrypt, and not
on encrypt...or (less likely) the encrypt side isn't throwing an error
when it should.

I assume you are talking about encrypted ODF 1.0/1.1 documents (and not, say, PDF or some Microsoft-format documents). ODF 1.0/1.1 used Blowfish for encryption, which is not sanctioned by FIPS mode, so trying to open such a document will indeed fail (with a somewhat unhelpful UI, claiming that any entered password is wrong). That LO allows saving such an encrypted document would appear to be a bug with that version of LO.

Note that LO recently gained support to forward some of its cipher-related operations to OpenSSL, see <https://gerrit.libreoffice.org/plugins/gitiles/core/+/4bc16aeb73c1201f187742e0fefe35521fae77ac%5E%21> "rhbz#1618703: Allow to use OpenSSL as backend for rtl/cipher.h". In a recent LO built with --enable-cipher-openssl-backend, trying to save an encrypted ODF 1.0/1.1 document should indeed fail (see <https://gerrit.libreoffice.org/plugins/gitiles/core/+/3cc6d3611ac8cbbfb9803f3a084d02edde470ad3%5E!/> "Related rhbz#1618703: Properly handle failure encoding zip file").

There is also some vague plans to allow decryption of existing documents even in FIPS mode, and to improve the UI in cases of failure caused by FIPS mode, but nothing implemented as of now. I don't think there's tracker bugs for that already at <https://bugs.documentfoundation.org/>; you could file such if you like (and please report back the ID(s) here).

--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.