背景：
我目前正在管理基于Ubuntu 14.04.1的服务器基础架构,并在应用所有当前的补丁时可用.
所有这些系统都是无头的,使用审核的预设和自动化工具自动构建,并通过基于Intel的统一硬件上的KVM在虚拟机中运行.
我们偏爱Ruby,但更倾向于“正确做事”.因为这两者,我们选择了“备份”宝石作为创建我们要保存的数据的加密存档的手段,因为它将为使用生产中的Vagrant的开发人员创建相同的加密存档,而不管机制如何它被传输.
所有的软件和配置都是通过Puppet管理的,所以决定都不会对“用户体验”或方便性产生任何影响.任一选项都将创建相关脚本来管理,验证或从任何创建的备份还原.
鉴于此,加密选项在为此目的使用时是否提供了其他优势？
解决方法
使用GPG,所有简单的错误都已被避免/修复,它为实际的加密选择了一个更长的“随机”密钥,并且执行了大量的“回合”,使其非常安全.
OpenSSL应该能够做所有相同的事情,(自1998年以来一直存在,但是如果版本号意味着在2010年达到版本1的任何版本),但是很容易犯一个可能会大大降低安全性的错误.而从this post on security.stackexchange.com(从2013年1月)and another由一个159K的信誉用户,openssl enc命令可能会留下需要的东西：
The encryption format used by OpenSSL is non-standard: it is “what OpenSSL does”,and if all versions of OpenSSL tend to agree with each other,there is still no reference document which describes this format except OpenSSL source code. The header format is rather simple:
magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f
salt value (8 bytes)Hence a fixed 16-byte header,beginning with the ASCII encoding of the string “Salted__”,followed by the salt itself. That’s all ! No indication of the encryption algorithm; you are supposed to keep track of that yourself.
The process by which the password and salt are turned into the key and IV is not documented,but a look at the source code shows that it calls the OpenSSL-specific 07002 function,which uses a custom 07003 with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented
-mdflag (!!!); the “iteration count” is set by theenccommand to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt),and that’s it.This is quite weak ! Anybody who knows how to write code on a PC can try to crack such a scheme and will be able to “try” several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU). If you use “openssl enc”,make sure your password has very high entropy ! (i.e. higher than usually recommended; aim for 80 bits,at least). Or,preferably,don’t use it at all; instead,go for something more robust (07004,when doing symmetric encryption for a password,uses a stronger KDF with many iterations of the underlying hash function).
男人甚至有这样的“BUGS”：
There should be an option to allow an iteration count to be included.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
