[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=84096#comment-84096 ] Alfred Hellstern commented on OFFICE-4153: ------------------------------------------ OP sent some questions to Microsoft which were reviewed by the Microsoft Crypto Board. Their answers to the original questions are in the document attached to this issue. > 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]