当我们想要做一次加密系统，或者只是有一个关于这个问题，它是如何保存的加密和解密密钥。
一般认为想要的文件加密和解密，对称算法用于。一般是AES要么DES。
这就存在密钥管理的问题，它是如何？
基本上两种方式：
1. 加密，然后密钥信息保存在文件外。比方我们把C: est.txt加密了，就生成一个密文。
然后把密钥保存在某个地方。比方数据库。我们能够在数据库里面添加一个记录，如：
path key
c: est.txt 123456789
当要解密的时候，就依据路径到数据库里面去查找相应的key，再进行解密。这么做有一个比較麻烦的问题。就是假设用户把这个文件copy到另外一个文件夹，那么就须要更新数据库。这就相当于我们须要监控这个文件c: est.txt的动态。
每一次移动copy什么的，都须要更新数据库，非常麻烦。
2. 定义一个自己的文件格式。
一般来说，会把密文放在自己定义文件的后面，前面加上一个文件头metadata。（也有把密文放在前面，metadata放在后面的）
这样的方式就会比第一种好一些，由于我们能够在metadata里面放入一些我们自己的数据。比方：密钥信息，tag啥的。
自己定义的文件格式就方便多了，假设用户移动了这个文件，也没关系，由于文件头metadata是跟着走的。
可是这里有个问题，就是metadata里面的某些信息是须要加密存放的。
我们总不可能把文件内容加密密钥明文放在metadata里面吧？假设这种话，仅仅要打开这个文件。就能够在头上看到加密密钥了。一下就能够解开密文了。
所以加密密钥本身也须要加密然后再放在metadata里面。
那么加密 “密钥”的密钥又放在哪里呢？
这个地方就须要有一个管理 （加密“密钥”的密钥） 模块。一般会把这个叫做KMC (Key Management Center)
加密 “密钥” 是使用非对称还是对称算法呢？
我认为都能够，详细看需求。
可是不管採用非对称还是对称算法。都须要一个KMC server。
假设是使用非对称算法的话，KMCserver须要产生一对key：公钥和私钥。把公钥发给client，client就能够用公钥把文件内容的密钥（如123456789...，AED256的话，就应该有32个字节）进行加密。然后把密钥密文放在metadata里面。
当须要解密的时候，有两种做法：a)把文件头（metadata）发给server。server用私钥把“文件内容密钥”解开，而且发回给client，这样client就能够用解开后的密钥解密文件内容了。
b) server把“文件内容密钥”密文相应的私钥发给client。client自己去解开得到文件内容密钥。然后再去解开文件内容。
假设使用对称算法加密“文件内容密钥”的话，也是类似的。
一个KMCserver肯定会有多个非对称密钥或者对称密钥的，所以。我们一般还须要一个id来标志密钥。通常的做法就是KMCserver会把公钥（非对称）或者密钥（对称）和相应的ID 发给client。client把文件内容密钥加密后。 KMC发过来的密钥就须要毁灭（以免在内存里面存在时间过长，而被人dump内存看到），然后把文件内容密钥的密文和相应id放在metadata里面。
举个样例，比方文件内容密钥是01234567890123456789012345678901
然后
1. 向KMCserver申请一个key（非对称，对称都行）
2. 用key把01234567890123456789012345678901进行加密可得xxxxxxxxxxxxx
3. 把key毁灭
4. 把密文xxxxxxxxxxx和相应的id比方10放到metadata。
例如以下图。
这样，当我们要解密的时候。能够把id：10发给KMCserver，KMCserver就会发回相应的key，然后就能够把xxxxxxxxx解开变成01234567890123456789012345678901了，这样就能够拿01234567890123456789012345678901来解开文件内容了。
（当然也能够把整个文件头发给KMC，让KMC直接解开xxxxxx,这个详细看设计）。
假设是自己定义文件格式。那么一般都是这么做的。
有几个地方须要注意一下：
1. client和KMCserver的通信最好要採用安全通信，比方ssl，不然那些密钥信息比較easy被人截获到。
2. 对于解密者的身份最好也要认证。不然谁都能够写一个exe来冒充你来和KMC进行通信了，一般使用数字证书就能够了。比方能够对exe进行签名等。
版权声明：本文博主原创文章，博客，未经同意不得转载。