文件加密不同于实时通讯加密在速度上要求不高，所以密钥数组可以做得更强大一些，这也就避免了什么流密码密钥混乱程度不够的偏见，要想信息安全密钥数组要做到唯一性，独一无二的密钥数组只能用一次，这样就避免了已知明文攻击的阴影。但是如果用户使用了相同的密码，如果生成密钥的方法固定仍然可以形成相同的密钥数组，这可以用一下两种方法解决：1）让加密软件自己生成用户密码，这样可以产生出随机性很强的用户密码，几乎没有重复的可能性；2）使用加盐（selt）技术，程序使用一些随机数作为用户密码的一部分，盐是需要妥善保存的，此时即使使用了相同的用户密码关系也不大了，这样也能解决用户使用相同密码的问题。

　　接下来是建造密钥数组，密钥数组的建造是在用户密码的影响下建造的，加密和解密时要使用同样的密钥数组才能让加密的信息复原如初，最好的办法是构造出一个密钥数组，根据明文的长度建造同样规模的密钥数组，已完成一一对应的加密和解密工作，密钥数组的长度有了，首先在数组中放置元素，所有用到的元素尽可能均匀地放在数组中，最初它们可以是顺序排列的，这样比较好处理，然后对这个数组进行随机排序以打乱原来的秩序，可以借助于优良的随机函数来完成排序，例如做一个循环来处理，先根据用户密码的计算值做成随机函数种子，数组的长度为循环变量，第一个数组成员和随机函数算出的数组长度范围内的一个值作为序号的数组成员进行数据交换，然后是第二个数组成员，余此类推到循环结束，这样所有的数组成员都被交换了，形成了新的数组，这样就完成了一次随机排序，必要时可以进行多次。根据笔者的经验如果数组长度超过所有元素总和的数倍以上数组才容易分布均匀，当密钥数组的尺寸较小时（例如小于元素总和数），初始数组应大于元素总和数的数倍，完成随机排序后再截取需要的长度以保证均匀分布，密钥数组很大时就无此必要了。例如字节数组有256个元素， 实测用1M的字节数组可以通过NIST标准全部15项检测，说明建造的数组是不错的。注意用户密码不可过短，过短容易被跟踪破解，极端的例子就 1位一个数做密码，很容易就被攻克，所以一般要设置用户密码个数的下限，但自动加盐的设计是不怕密码过于简单的。

　　这样造出的密钥是很难仿造的，对外来说，每个用户密码字节都是未知数，并且每个明文字节和密钥字节都是未知数，未知数的总和大于能够开列的方程数许多倍，从方程论的角度也是不可破解的。

　　有了密钥数组，对明文的加密就简单了，推荐使用加法作加密减法做解密，而不要用异或来做，后者的计算缺乏灵活性，例如连续多遍加密异或就不行了。明文字节依次和密钥字节做加法（无符号运算）得到密文字节，解密时密文字节和密钥字节做减法（无符号运算）就还原出明文字节了。明文或密文数组和密钥数组的结合方式可以是多种多样的，让用户密码来控制选用何种方式将造成丰富多彩的格局，使加密强度提高。

　　有人认为用穷举攻击可以解密所有的加密，这是一种谬见，而能让其得逞的正是加密软件本身，有些加密软件为了人性化设计成这样：当做解密操作时，如果密码错误软件将告诉你密码错误，这样破解者就可以编制一个软件展开穷举攻击，那个加密软件就沦落成一个错误密码筛选器成为破解自己密文的帮凶。如果人性化设计对信息安全造成损害那么不要也罢。正确的方法是：可以做少量密码正误的检测，但即使通过检测也不一定能完成解密，只有正确的密码才能完成解密，这样就不是完全出卖了自己，也实现了人性化设计。或者完全不做检测，这样虽少些人情味但安全性是最好的，自己加密的东西解密后是什么自己最清楚，密码输入错误自己再输入呗，用不着软件来提醒你。

　　上面看到自己做密钥数组虽然也很省事但实际上有没有必要？现实中许多随机函数就能生成随机性很好能通过NIST检测的数组，这些东西不能做密钥吗？答案是肯定的，尽管生成的数据之间有内在的连带关系，但由于它们只出现在计算过程中，你尽管知道用了什么函数，怎么用的想让这些信息对破解密文有所贡献是完全不可能的，因为其特征被其它数据淹没了。一旦破解者没有了软件提供的判断依据，他仍可以实行穷举攻击但是困难多多，他仍可以组织大量的伪用户密码给加密软件而得出伪明文，但想从中找出正解是太难了，因为各种形式的解是等概率的，你可能得到可以读懂但完全矛盾的解，这时你将无法判断谁是正解。如果明文本身就是乱码的话，那你的出路只有绝望。

　　严格的遵守规则加密软件不留漏洞不可破解就是常态，而破解才是奇迹。