[OASIS Issue Tracker] (OFFICE-4153) ODF password-based package encryption enhancements

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/OFFICE-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis Cave updated OFFICE-4153:
---------------------------------
    Fix Version/s:     (was: ODF 1.5)

> 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: 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)