3

Comments on https://gist.github.com/shadowhand/873637 state

"ECB mode encryption is a relatively simple method of encryption that provides a high level of obfuscation (or a low level of encryption). This method is not very secure and should not be used for sensitive personal data, but would work well for eg. transmitting source code between private parties in a public channel. For better security, you can switch the mode to CBC at the cost of having every file change completely for every modification. As with all encryption, a strong key is always recommended."

and

"This is kind of (part of) the definition of functionally correct encryption - ECB (click here for an explanation) is a flawed legacy implementation recommended by precisely nobody for current use today, and only supported in OpenSSL because OpenSSL supports some very old and creaky legacy crypto implementations! It's only useful today as a learning tool and should never be used in current systems.

CBC of OFB modes should be the default - please consider changing your gist to use CBC and explain the potential benefits of ECB along with the downsides for those who would like to accept the loss in security for slight convenience in git. Nothing should be insecure by default!"

http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.html however states that using a fixed-valued salt for CBC is bad crypto practice. If we switched the mode to CBC (for https://gist.github.com/shadowhand/873637 or https://github.com/shadowhand/git-encrypt), would it be using a fixed-value salt, and therefore be bad crypto practice?

(I've also posted this question as a comment on https://gist.github.com/shadowhand/873637 )

Daniel
  • 1,446
  • 1
  • 20
  • 35

1 Answers1

5

ECB is secure when it's used to encrypt unique blocks. For example, if you had a collection of secret keys, and want to all of them with a master key, ECB is a secure choice.

ECB is not secure when the same block could be encrypted multiple times. For example, long passages of natural language are likely to contain substrings that repeat. Or, multiple messages of a given protocol are likely to have the same prefix or suffix. Using ECB with such plain text will reveal patterns in the plain text.

The term "fixed-value salt for CBC" doesn't make any sense. "Salt" is used in key derivation—creating a secret key from a password. CBC requires an "initialization vector," which must be unpredictable for each message that is encrypted. (Some broken cryptographic protocols have, in the past, generated IVs and keys from a password; this is only secure if the password is used to encrypt only one message.) Ideally, an IV is generated by a cryptographic random bit generator; using a fixed IV in CBC mode can reveal patterns in message prefixes, much like ECB.

To know whether ECB is secure here, more context would be necessary (questions should be self-contained, and not include unnecessary information). However, a blanket statement that ECB is always insecure is false; it can be secure in the right application, and its shorter ciphertexts can sometimes be valuable.

erickson
  • 249,448
  • 50
  • 371
  • 469
  • Thanks. In this context, I think ECB is used to encrypt a code base. (It's used in the following line: openssl enc -d -base64 -aes-256-ecb ...). I would think that (as in long passages of natural language) a code base may also contain substrings that repeat, and consequently using ECB here is insecure. Does that make sense? – Daniel Jul 08 '15 at 19:49
  • Just noticed that github.com/shadowhand/git-encrypt mentions that a static salt must be used (and therefore using "CBC" would provide very little, if any, increased security over "ECB" mode). I'm guessing "static salt" means the same thing as "fixed-value salt", but I'm not sure about that. According to http://stackoverflow.com/a/5935372/805141 "...there is no such thing as a 'static salt'. If it is not random, it's not a salt but a key." – Daniel Jul 08 '15 at 19:57
  • Yes, encrypting source code with ECB would not be secure. Encrypting different source codes with CBC using the same IV would also be insecure. – erickson Jul 08 '15 at 20:11
  • @Daniel I found some time to read over all the commentary at github. I don't really understand the application here. Are these filters to be used so that a repo that is synced via Dropbox is encrypted? If that's the idea, I would suggest using Wuala instead of Dropbox. It seems like with this gist, only the file content itself would be encrypted, not any of the meta data, and there's probably a lot of information about the data in the meta data. The whole repo should be encrypted with an encrypting file system. – erickson Jul 09 '15 at 19:44
  • Thanks for doing that. I was under the impression that the solution was intended to be used with any service, not just Dropbox. That's a good point though. Anyway, I'm thinking of switching over to https://github.com/bluss/git-remote-gcrypt as I haven't found any security issues with it yet. – Daniel Jul 09 '15 at 22:25