Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


Thank's for your fast reply.

of course, but if you use an *actual* random function to derive the key from the salt and the password then you'll have trouble decrypting the resulting ciphertext...

Why should that be problematic? Randomly generated values ​​(for example, salt or initialization vector) are known because they are included in the unencrypted manifest.xml file. So the decryption algorithm (which is complete deterministic) has access to the values and there is no randomness in the decryption process.

both: the method specified in ODF applies the HMAC-SHA1 function to generate the key from the salt, not to generate the salt.

Ah, by that you mean the PRF, which used in the F()-function defined in RFC2898 on page 10, is the HMAC-SHA-1 function.

But how is the salt generated? The PBKDF2 key derivation method needs a Salt which is randomly generated:

In password-based encryption, the party encrypting a message can gain assurance that these benefits are realized simply by selecting a large and sufficiently random salt when deriving an encryption key from a password.
(at bottom on Page 5)


I looked at the referenced RFC 2898: "PKCS #5: Password-Based Cryptography Specification Version 2.0" (https://www.ietf.org/rfc/rfc2898.txt) how this will be made. In RFC 2898 at the end of page 6 and start of page 7 is written the following:

If a random number generator or pseudorandom generator is not available,

LibreOffice requires one.

available, a deterministic alternative for generating the salt (or the random part of it) is to apply a password-based key derivation function to the password and the message M to be processed. For instance, the salt could be computed with a key derivation function as S = KDF (P, M). This approach is not recommended if the message M is known to belong to a small message space (e.g., "Yes" or "No"), however, since then there will only be a small number of possible salts.

My question: Which method is implemented in LibreOffice? Does LibreOffice use a PRNG or the method specified in the ODF standard with the HMAC-SHA-1() function over the plaintext and (password)/(hash of the password))? The second one is a little bit insecure.

both: the method specified in ODF applies the HMAC-SHA1 function to
generate the key from the salt, not to generate the salt.

Or more precisely, LibreOffice uses a PRNG() to create a random salt. Is that correct?
If yes, does LibreOffice use a PRNG provided by the operating system?
If not, how is the salt generated?

Thanks many for your help.

Greetings

Steve

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.