OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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


Michael Stahl created OFFICE-4153:
-------------------------------------

             Summary: 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
             Fix For: ODF 1.5


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]