[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OFFICE-4153) ODF password-based package encryption enhancements
[ https://issues.oasis-open.org/browse/OFFICE-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=84098#comment-84098 ]
Michael Stahl edited comment on OFFICE-4153 at 2/1/24 10:19 AM:
----------------------------------------------------------------
thanks Alfred for the answers! please forward my replies...
there seems to be nothing to discuss on points 1. and 3.
Â
_2. When using AES-GCM or AES-CCM it is critically important to generate the nonce values properly, considering that each Nonce value may be used at most one time for encryption for any given key._
_There will be a chance that the nonce may be repeated for the same password (which I assume will derive into the same key). This needs to be carefully considered, especially since users are likely to use the same password for different/independent files._
our customer's cryptographic expert mentioned the risk too.
the assumption, however, is wrong: the way it works (see step 4 in the description), the key derivation function (PBKDF2 or Argon2 in the proposal) already gets a random salt (128-bit) as additional input, so the same password should practically never result in the same key.
in addition, in LibreOffice the nonce/IV for the encryption is again 96-bit random data (the W3C specification of AES-GCM requires exactly this size).
of course this requires a good source of cryptographic randomness; LibreOffice uses urandom(4) or RtlGenRandom (depending on platform).
(edit: ODF also supports OpenPGP public key encryption; in this case, LibreOffice uses 256 bits of random data as the key, which is stored (public-key-encrypted) in the <manifest:PGPKeyPacket> element)
* _Using AEAD with AES-CBC + HMAC. This may be a much simpler & easier to implement option, and it is OK using a random IV._
agreed that this could work; it has its own complications though (i read somewhere that one should not use the same key for the AES and HMAC functions; and that one should first encrypt, then hash the encrypted data).
* _An alternative to use AES-GCM would be generating a new random AES key for each message being encrypted (i.e. upon every âdocument saveâ operation) :_
yes, that is already done.
i believe the sub-points here describe an alternative way to randomize the key that isn't needed for ODF due to the random salt given to the KDF.
(i note in passing that, just like myself, the authors didn't have an idea of anything to use as "additional data" input to the AEAD function.)
Â
_4. Argon2 is not currently a FIPS 140-3 approved algorithm, however it is likely that by the time v1.5 is evaluated there would be changes to SP 800-132 ({color:#518b9b}+[Decision to Revise NIST SP 800-132 / CSRC|https://csrc.nist.gov/News/2023/decision-to-revise-nist-sp-800-132]+{color}) that would change its status. Assuming Argon2 becomes FIPS 140-3 approved by that time, we agree it would be a welcomed change; otherwise, we would need to discuss it in more detail in the future to find a way to meet FIPS 140 compliance._
that sounds promising!
so while we would prefer to use Argon2 (and add the additional attributes for its parameters to the manifest RelaxNG schema), it is still possible to use PBKDF2 instead, as everything is configurable with XML attributes, and LibreOffice will be able to consume such a file.
our customer's cryptographic expert recommended to increase the PBKDF2 iterations to 600k.
was (Author: info6):
thanks Alfred for the answers! please forward my replies...
there seems to be nothing to discuss on points 1. and 3.
Â
_2. When using AES-GCM or AES-CCM it is critically important to generate the nonce values properly, considering that each Nonce value may be used at most one time for encryption for any given key._
_There will be a chance that the nonce may be repeated for the same password (which I assume will derive into the same key). This needs to be carefully considered, especially since users are likely to use the same password for different/independent files._
our customer's cryptographic expert mentioned the risk too.
the assumption, however, is wrong: the way it works (see step 4 in the description), the key derivation function (PBKDF2 or Argon2 in the proposal) already gets a random salt (128-bit) as additional input, so the same password should practically never result in the same key.
in addition, in LibreOffice the nonce/IV for the encryption is again 96-bit random data (the W3C specification of AES-GCM requires exactly this size).
of course this requires a good source of cryptographic randomness; LibreOffice uses urandom(4) or RtlGenRandom (depending on platform).
* _Using AEAD with AES-CBC + HMAC. This may be a much simpler & easier to implement option, and it is OK using a random IV._
agreed that this could work; it has its own complications though (i read somewhere that one should not use the same key for the AES and HMAC functions; and that one should first encrypt, then hash the encrypted data).
* _An alternative to use AES-GCM would be generating a new random AES key for each message being encrypted (i.e. upon every âdocument saveâ operation) :_
yes, that is already done.
i believe the sub-points here describe an alternative way to randomize the key that isn't needed for ODF due to the random salt given to the KDF.
(i note in passing that, just like myself, the authors didn't have an idea of anything to use as "additional data" input to the AEAD function.)
Â
_4. Argon2 is not currently a FIPS 140-3 approved algorithm, however it is likely that by the time v1.5 is evaluated there would be changes to SP 800-132 ({color:#518b9b}+[Decision to Revise NIST SP 800-132 / CSRC|https://csrc.nist.gov/News/2023/decision-to-revise-nist-sp-800-132]+{color}) that would change its status. Assuming Argon2 becomes FIPS 140-3 approved by that time, we agree it would be a welcomed change; otherwise, we would need to discuss it in more detail in the future to find a way to meet FIPS 140 compliance._
that sounds promising!
so while we would prefer to use Argon2 (and add the additional attributes for its parameters to the manifest RelaxNG schema), it is still possible to use PBKDF2 instead, as everything is configurable with XML attributes, and LibreOffice will be able to consume such a file.
our customer's cryptographic expert recommended to increase the PBKDF2 iterations to 600k.
> ODF password-based package encryption enhancements
> --------------------------------------------------
>
> Key: OFFICE-4153
> URL: https://issues.oasis-open.org/browse/OFFICE-4153
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: New Feature
> Components: Packaging, Part 2 (Packages) [1.2: 3], Security
> Reporter: Michael Stahl
> Priority: Major
> Attachments: Microsoft Crypto Board answers to questions originally asked by Michael Stahl Oct 2023.docx, odf-manifest-schema-v2.diff, odf-manifest-schema-v3.diff, odf-manifest-schema.diff
>
>
> h3. Current situation
> Encryption is currently specified in ODF 1.4 Part 2, 3.4 "Encryption" and individual elements and attributes in 4.*.
> Currently for password-based encryption an ODF package, every file entry in the package is stored following these steps:
> 1. original size and checksum of first 1KiB of plain text are stored as attributes (to enable verifying the password on decryption)
> * manifest:size
> * <manifest:encryption-data>
> ** manifest:checksum, manifest:checksum-type
> 2. file data is compressed with "deflate"
> 3. password entered by user is hashed once (typically with SHA256)
> * <manifest:start-key-generation>
> ** manifest:start-key-generation-name
> ** manifest:key-size
> 4. salt is randomly generated, KDF is applied to result of step 3 (typically PBKDF2)
> * <manifest:key-derivation>
> ** manifest:salt
> ** manifest:iteration-count
> ** manifest:key-derivation-name
> ** manifest:key-size
> 5. initialization vector is randomly generated, file data is encrypted (typically AES256 CFB)
> * <manifest:algorithm>
> ** manifest:initialisation-vector
> ** manifest:algorithm-name
> 6. the encrypted file data is STORED (uncompressed) in the ZIP package
> h3. Problems
> There are problems with this approach:
> 1. deriving a new key for each file entry is wasteful and in practice a serious performance problem
> 2. PBKDF2 is susceptible to brute-forcing with GPUs, requiring large number of iterations to mitigate [https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pbkdf2-sha256]
> 3. there is no authentication of the encrypted data
> 4. information is leaked, most importantly the SHA/1k checksums, and also names and sizes of file entries
> Problems 3 and 4 also affect PGP encrypted ODF packages.
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]