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


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

Regina Henschel commented on OFFICE-4153:
-----------------------------------------

3.4.1 General
Fundamentally, there are 2 ways to encrypt an OpenDocument package. In every version of OpenDocument, it has been possible to encrypt every file entry in the package separately. That method is specified in section 3.4.2. With OpenDocument 1.5, it is now possible to encrypt the whole package at once, which is considered a better approach as it is both more efficient and more secure. That method is specified in section 3.4.3.

3.4.2 Separate file encryption
3.4.2.1 General (was 3.4.1 in ODF 1.4)
...
3.4.2.2 Encryption Process (was 3.4.2 in ODF 1.4)
...

3.4.3 Wholesome encryption
An OpenDocument package can be produced in the usual way (without encryption), and then wrapped in an outer OpenDocument package in an encrypted file entry with the special name "encrypted-package". This is called "wholesome encryption".
The encrypted wrapper package should contain only the files "mimetype" and "encrypted-package", and files in "META-INF/".
The needed information to decrypt the "encrypted-package" file are stored in the manifest file as specified in section 4.

Note: Current best practice is to use wholesome encryption with SHA256 start key derivation, Argon2id key derivation function and AES-GCM authenticated encryption algorithm.

> 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]