I need to send an Excel file to someone, normally I would use encrypted e-mail, however, this is not an option with this individual. What is the minimum length password I can apply to this file to get a decent level of protection and is there a way to mathematically compute the strength of a password?
1 Answer
$\begingroup$
$\endgroup$
6
Excel 2007 (12.0) and up uses an iterated hash and AES encryption by default if you use the native, non-backwards compatible XML format (.xlsx), so the weak point is for sure the password. Depending on how safe you need to keep the document, you can use simple passwords, or you can use more complex character sets and combinations of words. If you are using an earlier version of Office or not using the .???X file format, assume it is insecure.
The encryption process itself uses with Windows crypto provider, and the default settings are generally secure; AES 128-bit encryption in CBC mode on 4KB chunks of data, the OS random number generator for salt and IV based on that salt, and an iterated hash (at least 50000) based on SHA-1 or SHA-2, depending on the version of Office. These settings be changed, if you are concerned I would suggest checking the encrypted document, the XML format will define the type of encryption used.
For high security, I require an 80-bit strong password. If you are using random characters from the default alphanumeric 62 character set, a secure password length is 14 characters, and would be considered unbreakable by normal means, 22 characters would match the strength of AES.
If your password is NOT random characters (rather actual words or phrases), then there are methods to estimate password strength, but they can be very inaccurate, usually telling you it is stronger than it really is. Easy to remember words and phrases are generally easier to crack, the algorithms used by password cracking software are quite effective at cracking even long passwords if the password is not random.
If you need actual words, I suggest you choose at least 6 random words from the dictionary that are at least 5 characters long. You can also use the PGP wordlist, which allows you to easily use bytes from a random number generator to get them. You would need at least 10 words to be secure, and 16 to match the strength of AES. Other wordlists are acceptable, such as the diceware list, if you are aware of how much strength there is per word (12.9 bits for diceware).
answered May 17, 2017 at 1:38
-
1$\begingroup$ +1 for sound general advice. Is there a public source for the initial proposition? How many hash iterations, or (if not constant) how can it be found in ciphertext? Version this applies to? Additional hypothesis are required to conclude that a 80-bit strong password is the weak point: that there is no key leak (e.g. key escrow using public-key encryption under a master key, or key-related bits "accidentally" left in undocumented, apparently unused ciphertext spots); if there is a random intermediary key, or IV for CTR/OFB mode, that the RNG is good enough... $\endgroup$– fgrieu ♦Commented May 17, 2017 at 6:03
-
1$\begingroup$ The 2007 and later XML type office formats (.xlsx, etc) use symmetric AES-128-CBC by default for encryption, and PBKDF2-SHA1 with a 128-bit salt and 50000 or higher iter, by default, and it uses a clearly defined process for encryption using the Windows cryptographic service provider $\endgroup$ Commented May 17, 2017 at 7:05
-
$\begingroup$ it looks like the key derivation is not quite PBKDF, but is based on it, and allows different keys for different blocks of data inside the file, so that if the blocks are the same they do not give the same ciphertext $\endgroup$ Commented May 17, 2017 at 7:40
-
1$\begingroup$ As an alternative (and not restricted to exel files), 7zip and other packaging software can be used to encrypt files. Regarding it's security, this question on security-SE takes a look at 7zip (and on TrueCrypt). Also see the security note on Wikipedia about DLL hijacking regarding the self-extracting archives. $\endgroup$– tyloCommented May 17, 2017 at 8:22
-
1$\begingroup$ @Richie Frame: With "sound general advice" I refer to you considering that 80 bits of password entropy is fine for most uses (when stretched to a key by even barely passable means, as you report). My "additional hypothesis are required" refers to the possibility of goofs or backdoors, as exemplified. My "initial proposition" refers to your original "Excel uses an iterated hash and AES encryption". $\endgroup$– fgrieu ♦Commented May 17, 2017 at 8:45