‘壹’ c#的AES加密解密问题
不是初学，而是对.net中所有的加解密方式都没有弄清楚。不过别灰心——很多自以为会的人也没有弄清。
首先，.net中类库中支持各类摘要加解密方式。一般情况下我们将安全分为两类，一类是摘要，一类是加解密。加密解又分为对称与非对称加解密。
在.net体系中，不管是摘要还是加解密，为了统一算法方式，一律都是流方式进行的。不管是MD5摘要还是ADE/DES/TDES/RSA等等。一定要记住的第一条，是流方式进行的！
流——这个概念很多人也不清楚，因为stream的范围还是非常的大的，有网络流responseStream等，基本文本流，IO流等等，在加密时我们使用了一个流叫“加解密流”CryptStream，该流用来实现加解密及摘要算法等等。
那么CryptoStream是个什么流呢？它算是转换流，把一种形式转换成另一种形式，比如把密文转换成明文或把明文换成密文。正常的情况下，我们可以用流写流的方式来实现，比如MemoryStream来换流。当然，也可以把byte[]数组直接写到流中。
流这部分说完了，那么，其实我们如何区别CryptoStream是加密还是解密呢，除了说明之外，还是一个方式，就是看流的方式是读还是写！所以当我看到你的解密流中使用的方式竟然是Write,而不是Read，所以你对加解密方式并没有真正理解。
比如，我们可以转换后的流直接进行ReadToLine即可。
老实说，你这种写法有很大问题——有关stream大部分都是非托管，所以一定要记着Dispose，或Close（Close时会自动调用Dispose)。防止出现错误等内存泄露。
有于加解密流，我们经常一句话，加密方式是Write,解密方式是Read!
‘贰’ php AES加密 openssl解密失败，帮忙看下代码哪里有问题
用Zend的加密吧，但是还是可以解密的，这也没办法，凡是对称加密或非不可逆的加密算法，均可以解密，这只是时间问题。
特别是没有密码的加密（不可逆除外）。
可以这样，使用AES加密，再用GZIP压缩，然后运行时解密，在eval那些代码。
前提是每个加密的文件的密码都不同，要购买才可以解密运行。
‘叁’ 为什么windows下aes解密android上的加密文件失败
1.程序加密可结合AES算法，在程序运行中，通过外部芯片中的AES密钥，加密数据来验证双方的正确性，称之为对比认证。2.加密数据传输过程中，可通过AES加密后形成密文传输，到达安全端后再进行解密，实现数据传输安全控制。3.综合1和2，当前高大上的方式是程序加密可进行移植到加密芯片，存储在加密芯片中，运行也在加密芯片内部运行，输入数据参数，返回执行结果，同时辅助以AES加密和认证，实现数据程序的全方位防护
‘肆’ java编程一个AES加密txt文件的程序，其中AES解密文件的方法出错，求大神搭救
你是对文件内容加的密，应该和文件类型无关把。如果用的是
AES算法加的密的话，初始化的时候就会写到
keygen = KeyGenerator.getInstance("AES");
//生成密钥
deskey = keygen.generateKey();
//生成Cipher对象,指定其支持的DES算法
c = Cipher.getInstance("AES");
加密和解密的过程几乎是一样的，AES是对称加密方式，你看看加密和解密方法里的有没有写错的地方。
‘伍’ php AES加密 openssl解密失败，帮忙看下代码哪里有问题
请放上代码
使用VS2005下的Visual Studio 2005 Command Prompt进入控制台模式（这个模式会自动设置各种环境变量）
、解压缩openssl的包,进入openssl的目录
、perl configure VC-WIN32
尽量在这个目录下执行该命令，否则找不到Configure文件，或者指定完整的Configure文件路径。
、ms\do_ms
在解压目录下执行ms\do_ms命令
、nmake -f ms\ntdll.mak编译后在openssl解压目录下执行，完成编译后。输出的文件在out32dll里面，包括应用程序的可执行文件、lib文件和dll文件
注意：在运行第五步时，cl编译器会抱怨说.\crypto\des\enc_read.c文件的read是The POSIX name for this item is deprecated（不被推荐的），建议使用_read。呵呵，我可不想将OpenSSL中的所有的read函数修改为_read。再看cl的错误代码 error C2220，于是上MSDN上查找：
warning treated as error - no object file generated
/WX tells the compiler to treat all warnings as errors. Since an error occurred, no object or executable file was generated.
是由于设置了/WX选项，将所有的警告都作为错误对待，所以。。。
于是打开OpenSSL目录下的MS目录下的ntdll.mak文件，将CFLAG的/WX选项去掉，存盘。
‘陆’ AES 加密解密爬坑
加密，要长度为 （16 *n）,则getInstance("AES/ECB/NoPadding")中NoPadding是关键
public static byte[] encrypt(byte[] key, byte[] data) throws Exception {
SecretKeySpec skeySpec = new SecretKeySpec(key, "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");//"算法/模式/补码方式"
cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
byte[] encrypted = cipher.doFinal(data);
return encrypted;
}
public static byte[] decrypt(byte[] key, byte[] data) throws Exception {
SecretKeySpec skeySpec = new SecretKeySpec(key, "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");
cipher.init(Cipher.DECRYPT_MODE, skeySpec);
byte[] decrypted = cipher.doFinal(data);
return decrypted;
}
‘柒’ AES加解密使用总结
AES, 高级加密标准, 是采用区块加密的一种标准, 又称Rijndael加密法. 严格上来讲, AES和Rijndael又不是完全一样, AES的区块长度固定为128比特, 秘钥长度可以是128, 192或者256. Rijndael加密法可以支持更大范围的区块和密钥长度, Rijndael使用的密钥和区块长度均可以是128，192或256比特. AES是对称加密最流行的算法之一.
我们不去讨论具体的AES的实现, 因为其中要运用到大量的高等数学知识, 单纯的了解AES流程其实也没什么意义(没有数学基础难以理解), 所以我们今天着重来总结一些使用过程中的小点.
当然了分组密码的加密模式不仅仅是ECB和CBC这两种, 其他的我们暂不涉及.
上面说的AES是一种区块加密的标准, 那加密模式其实可以理解为处理不同区块的方式和联系.
ECB可以看做最简单的模式, 需要加密的数据按照区块的大小分为N个块, 并对每个块独立的进行加密
此种方法的缺点在于同样的明文块会被加密成相同的密文块, 因此, 在某些场合, 这种方法不能提供严格的数据保密性. 通过下面图示例子大家就很容易明白了
我们的项目中使用的就是这种模式, 在CBC模式中, 每个明文块与前一个块的加密结果进行异或后, 在进行加密, 所以每个块的加密都依赖前面块的加密结果的, 同时为了保证第一个块的加密, 在第一个块中需要引入初始化向量iv.
CBC是最常用的模式. 他的缺点是加密过程只能是串行的, 无法并行, 因为每个块的加密要依赖到前一个块的加密结果, 同时在加密的时候明文中的细微改变, 会导致后面所有的密文块都发生变化. 但此种模式也是有优点的, 在解密的过程中, 每个块的解密依赖上一个块的加密结果, 所以我们要解密一个块的时候, 只需要把他前面一个块也一起读取, 就可以完成本块的解密, 所以这个过程是可以并行操作的.
AES加密每个块blockSize是128比特, 那如果我们要加密的数据不是128比特的倍数, 就会存在最后一个分块不足128比特, 那这个块怎么处理, 就用到了填充模式. 下面是常用的填充模式.
PKCS7可用于填充的块大小为1-255比特, 填充方式也很容易理解, 使用需填充长度的数值paddingSize 所表示的ASCII码 paddingChar = chr(paddingSize)对数据进行冗余填充. (后面有解释)
PKCS5只能用来填充8字节的块
我们以AES(128)为例, 数据块长度为128比特, 16字节, 使用PKCS7填充时, 填充长度为1-16. 注意, 当加密长度是16整数倍时, 反而填充长度是最大的, 要填充16字节. 原因是 "PKCS7" 拆包时会按协议取最后一个字节所表征的数值长度作为数据填充长度, 如果因真实数据长度恰好为16的整数倍而不进行填充, 则拆包时会导致真实数据丢失.
举一个blockSize为8字节的例子
第二个块中不足8字节, 差4个字节, 所以用4个4来填充
严格来讲 PKCS5不能用于AES, 因为AES最小是128比特(16字节), 只有在使用DES此类blockSize为64比特算法时, 考虑使用PKCS5
我们的项目最开始加解密库使用了CryptoSwift, 后来发现有性能问题, 就改为使用IDZSwiftCommonCrypto.
这里咱们结合项目中边下边播边解密来提一个点, 具体的可以参考之前写的 边下边播的总结 . 因为播放器支持拖动, 所以我们在拖拽到一个点, 去网络拉取对应数据时, 应做好range的修正, 一般我们都会以range的start和end为基准, 向前后找到包含这个range的所有块范围. 打比方说我们需要的range时10-20, 这是我们应该修正range为0-31, 因为起点10在0-15中, 20 在16-31中. 这是常规的range修正.(第一步 找16倍数点).
但是在实际中, 我们请求一段数据时, 还涉及到解密器的初始化问题, 如果我们是请求的0-31的数据, 因为是从0开始, 所以我们的解密器只需要用key和初始的iv来进行初始化, 那如果经过了第一步的基本range修正后, 我们请求的数据不是从0开始, 那我们则还需要继续往前读取16个字节的数据, 举个例子, 经过第一步修正后的range为16-31, 那我们应该再往前读取16字节, 应该是要0-31 这32个字节数据, 拿到数据后,使用前16个字节(上一个块的密文)当做iv来初始化解密器.
还有一个要注意的点是, 数据解密的过程中, 还有可能会吞掉后面16个字节的数据, 我暂时没看源码, 不知道具体因为什么, 所以保险起见, 我们的range最好是再向后读取6个字节.
感谢阅读
参考资料
https://zh.wikipedia.org/zh-cn/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86
https://segmentfault.com/a/1190000019793040
https://ithelp.ithome.com.tw/articles/10250386
‘捌’ 为什么windows下aes解密android上的加密文件失败
你的Cipher生成好像缺了很多步聚，而且如果只需要加／解密，用CipherInputStream和CipherOutputStream应该更方便。
我把你的代码完整改了一下（几乎面目全非）。已包含加密和解密的方法，一套即用。除了Cipher生成那方法比较难明外，其他部份都很简单，相信你一看就明。
‘玖’ uniappaes解密前面部分乱码
每次加解密都需要重新生成一个AES对象。
在CBC模式，同个AES对象，所有之前的加解密会影响下一次加解密(加密解密谁先谁后影响都一样)，因为CBC是Blockchained的，加密的时候是串行的，需要依赖上个块的加解密结果，可以理解为它是有记录中间状态的过程，所以下一次加解密使用原来的AES对象存在问题，ECB模式则没有这个问题，解决方法：每次加解密都需要重新生成一个AES对象。
乱码是指由于本地计算机在用文本编辑器打开源文件时，使用了不相应字符集而造成部分或所有字符无法被阅读的一系列字符。乱码包括文本乱码、文档乱码等。