On 03/21/2014 10:05 PM, Michael DeHaan wrote: > quoted: " Auditing capabilities. You still cannot tell whether a > specific secret has changed and by whom. A structure that allows the > provability of the source of a security breach is quite important, > especially in environments that need to conform to security standards." > > Eh, I'm not sold. While it's possible to make arguments in both > directions, it is just as easy to state that letting someone know > *WHAT* variables are entered into the file makes it more easy to say > "this is the file I want to crack". The other thing is that the > encrypted values for each "leaf" are going to be crazy long and you > are also encrypting *less* data in each. If you do need the data > about what changed, you *STILL* have the history of changes on the > file, who made them, and can decrypt each step if you really wanted. > The data isn't lost. >
You would say "this is the file I want to crack" for a fully encrypted file too (it must have something important to be encrypted in the first place). Also, with AES and PKCS5 padding the cipher-text length can be calculated as: (original_length / 16 + 1) * 16. So a secret 16 bytes long would be encrypted to 32 bytes of cipher-text. Probably you will also store the IV (16 bytes), so you end up with 48 bytes. You will also base64-encode this to have finally a ~65 bytes long string. So, ok, you will have about 4 times longer strings. Why is this a problem? Moreover, with leaf-node encryption you are not encrypting *less* data. You are only encrypting the part of data that *needs to be secret*. As for the auditing part, things are not so simple. If you commit files encrypted as a whole, auditing data may be possible (just possible, not easy) only if passwords to decrypt them are or can be available. But passwords can be forgotten if they are stored in human minds, or can be deleted (deliberately or by accident) if stored in password stores. Normally, you would only have to recreate your secrets in these cases and replace the old ones. With whole file encryption this is not enough. Besides losing your passwords, you also lose your whole data structures, that you will have to rewrite. Also, who is going to be the auditor? If he is an outsider (as security requirements may demand), is he trusted? Can you pass him the passwords to your clear text secrets? Even if all these are not a problem for you, to make auditing possible with whole-file encryption commits, you would still have to create your own tool that would involve checking out revisions, decrypting them, running out-of-rcs-history diffs between them and producing an output in a meaningful format with all needed information (commiter, timestamps, etc.). Not easy. With leaf-node encryption commits, you wouldn't need that. You would just use the history tools provided by your rcs. Your data structures and their history would not depend on passwords and you would be able to take full advantage of the distributed nature of your rcs in case of a central infrastructure attack. > As an aside, I will correct myself -- the password lookup plugin > generates passwords, so it's not really an answer to this problem to > make a password plugin using VaultLib. > > However, it should also be noted that the approach of "leaf node > encryption" doesn't work for other reasons -- people will quickly want > a file *half* encrypted, see OP's post, which just makes everything > get really complicated real quick. > I cannot see what that *half* encrypted file problem is in the OP's post. As I said, with leaf node encryption you are only encrypting your secrets in leaf nodes, not your whole data structures. > I'm open to an ansible.cfg option pull request that might enable a > mode like this, but it needs to be off by default. > This is really nice. :) -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/532D5DD0.9060708%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
