并行加密

❶ 最简人机交互-加解密

上学时递小纸条，尤其是需要中间人传递时，是不是使用过一套约定的符号代替普通的文字？特别有必要！
图
广义来讲，保护信息的各种方式都属于加密范畴，而保护的形式、角度、等级和目标是多种多样的。

电视剧里，经常有材料被情敌偷偷修改然后蒙冤的场景。何解？
策略：让内容中每一个字节都参与一项运算得出一个结果记录下来，如果计算结果变了，说明内容被修改过。

这里运算得出的结果叫做摘要，这个算法叫消息摘要算法，也叫单向散列函数。算法的科学性很重要，常见的算法有：MD5、SHA1、SHA256、SHA512、HmacMD5、HmacSHA1、HmacSHA256 等。

这个，只能说难免会被别人看到。
策略：使用密钥变换内容，让别人看到也不知道为何物，通过密钥才可还原内容。

这种通过相同的密钥来加密和解密的算法，叫对称加密算法。常见算法DES、3DES（TripleDES）和AES（Advanced Encryption Standard）等。AES 根据密钥长度不同又分为AES-128 AES-192 AES-256 对应16 24 32 字节。

这些算法，通常是按块来进行加密的，如 16 个字节为一块。当最后一块不够 16 个字节时，通常是采用补齐的策略，补齐的方式也有不同讲究。
策略一，数据长度不对齐时使用0填充，否则不填充，但补的0解密后无法区分是补的还是原本就有的，只适合以\0结尾的字符串加密，此谓之 ZeroPadding。
策略二，补充的字节值设定为补充的数量，如要补充5个字节，则这5个字节的值都为 5，这样根据最后一个字节可得到填充数据的长度，在解密后可以准确删除填充的数据。但如果刚好整块无需补充，为了仍然满足最后一个字节表示填充的数据长度，填充一整块，值为块长度。此种方式有 PKCS7Padding，它假设数据长度需要填充n(n>0)个字节才对齐，那么填充n个字节，每个字节都是n；如果数据本身就已经对齐了，则填充一块长度为块大小的数据，每个字节都是块大小。PKCS5Padding，PKCS7Padding的子集，块大小固定为8字节。

分块加密时，每块采用完成相同的加密过程，则可以并行加密再拼接，但当内容中有多块相同的内容时加密结果会一样，而这种重复会为破解提供线索，于是多种加密模式被提出。以下是两种最常见的模式。

Electronic Code Book(ECB)
电子密码本模式
最基本的加密模式，也就是通常理亏洞解的加密，相同的明文将永远加密成相同的密文，无初始向量，容易受到密码本重放攻击，一般情况下很少用。

Cipher Block Chaining(CBC)
密码分组链接模式
明文被加密前要与前面的密文进行异或运算后再加密，因此只要选择不同的初始向量，相同的密文加密后会形成不同的密文，这是目前应用最广泛的模式。CBC加密销饥枯后的密文是上下文相关的，但明文的错误不会传递到后续分组，但如果一个分组丢失，后面的分组将全部作废(同步错误)。

对称加密中，接收方需要知道密钥，这个密钥本身的保密就成为了问题。密钥泄漏，意味着正确解密的消息也变得不可靠，也许是伪造的。

策略：公开密钥，即发给我的消息，使用公开密钥加密，我收到之后只可用我的私有密钥解密。

此谓之非对称加密算法，一种强大的密钥保密方法。这离不开理论上的研究成果。

非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。

为了验证是不是对的人，可以要求发送放对内容提取摘要，并使用其私钥加密，将结果附在后边作为签名一并发送。这样，就可以使用发送放的公钥来解密这个签名并验证其一致性，如果一致说明是对的人发过来的。此过程谓之签名验签。

使用最广泛的是RSA算法。

很多常见的加密算法在 CryptoJS 中有实现，首先，在控制台引入扩展脚本。肢让

加密结果 U2FsdGVkX1//4p9CUaZpnBxvOKT
解密过程

加密的内容为16进制数据时，可以利用以下方式将16进制字符串转换成字节数组。

计算结果

CryptoJS 当前尚未支持 RSA，可以引入以下 JS 扩展。

使用公钥加密

/hTwEJsz+/TkaF5UKG+H+RrjpbHHQVe3mWWlDsX9bZ/m8lP3izntwKHdklH+2vfeOlSJ3+PK3O6ILWvaVM4PVCzVo9lPiN7NkIE=

使用私钥解密

反过来使用私钥加密公钥解密也是可以的，只是一般的工具方法，只会提供私密生成签名，公钥验证签名，但这足够了。
更详细用法，请参考 https://github.com/travist/jsencrypt/

直接来看看二战期间的故事，以下内容引用自 https://..com/question/13366735.html

❷ 只有USB口的手提电脑怎么接并行口的“加密狗”

如果该机器没有并口的扩展卡或者底座，那就没办法了

❸ 如何查看并行加密狗端口是否工作

插上加密狗只能控制某早念基个程序的端口，但必须要跟加密狗对应的程序端口 ， 是点对点控制。

加密狗不能直接控制电脑上应用程序的端口，只能编写一个程序监控80这个端口同时监控是否插入加密狗，如果已经插入狗，就放行http协议的数据，否则阻止。

设置一个监控端口的陆谨进程，也就是高渗说一共有3个进程一个是开启一个是关闭，一个是监控服务状态。

❹ 利用usb口和计算机并行口实现对数据加密属于硬件加密吗

属于硬件加密，就必须要考虑计算机接口的问题。计算机的接口有许多种，如传统的串口和并口。串口的出现是在1980年前后，数据传输率是115～230kb/s，一般用来连接鼠标和外置Modem;并口的数据传输率比串口快8倍，标准并口的数据传输率为IMb/s左右，一般用来连接打印机、扫描仪等。早期的软件狗类加密硬件基本上都是使用并口的，不但极易与打印机冲突，而且容易被破解。要想设计出更可靠更完善的加密硬件，必须采用新的计算机接口。而近年来发展快速的USB接口技术为硬件加密提供了一条很好的道路。
1 总体方案的提出
设计系统原则是在实用、可靠、经济的原则基础上，保证系统不仅能满足应用需要，而且要有灵活性、可扩展性和通用性。该系统有EDA技术、USB 总线协议、加密算法优化组合而成，系统的构成如图1所示。FPGA的作用之一是和PDIUSBD12进行通信，实现USB协议，从PDIUSBD12中获取数据并根据主机的要求发送数据。第二个作用就是加密算法的实现，完成传送数据的加密。
2 USB协议的实现
2.1 PDIUSBD12简介
PDIUSBD12是Philips公司的一款较新型的专用USB通信控制芯片，符合USBI.1规范，是一款高性能USB接口器件，集成了SIE，FIFO存储器，收发器以及电压调整器。可与任何外部微控制器/微处理器实现高速并行接口（2 MB/5），在批量模式和同步模式下均可实现IMB/5的数据传输速率以及完全自治的直接内存存取DMA操作。

❺ 并行口加密狗换945主板不能用

这个应该是加密狗的兼容性不好，尤其是年代携芦毁久辩备远的加密狗，你哗前可以试试安装加密狗的最新驱动，也许会解决你的问题，如果是在搞它不定，就看看这里的介绍http://hi..com/nusbm

❻ 在CBC模式里有可能对多个明文分组进行并行加密吗解密呢

加密不行，但是解密可以

❼ AES加密算法原理

一般的加密通常都是块加密，如果要加密超过块大小的数据，就需要涉及填充和链加密模式，本文对对称加密和分组加密中的几种种模式进行一一分析(ECB、CBC、CFB、OFB,CTR)

这种模式是将整个明文分成若干段相同的小段，然后对每一小段进行加密。

优点:

这种模式是先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密。

优点：

计算器模式不常见，在CTR模式中， 有一个自增的算子，这个算子用密钥加密之后的输出和明文异或的结果得到密文，相当于一次一密。这种加密方式简单快速，安全可靠，而且可以并行加密，但是 在计算器不能维持很长的情况下，密钥只能使用一次 。CTR的示意图如下所示：

优点：

优点：

优点：

❽ 我们应该使用 TLS1.3 吗

SSL（Socket Layer Security）和 TLS（Transport Layer Security） 都是属于安全协议，主要作用是保证客户端和服务端之间能安全通讯。SSL是较早的协议，TLS 是 SSL的替代者。

SSL 版本 1.0、2.0 和 3.0，TLS 版本 1.0、1.2 和 1.3。SSL协议和TLS1.0 由于已过时被禁用，目前TLS 1.3 是互联网上部署最多的安全协议，它是TLS最新版本 ，它增强了过时的安全性，并增加了更多的触控性。通过下面几点可以有个简单认识：

现代浏览器支持 TLS 1.2 和 TLS 1.3 协议，但 1.3 版本要好得多。 TLS 1.3 对早期版本进行了多项改进，最明显的是简化了TLS握手操作，使得握手时间变短、网站性能得以提升、改善了用户体验，另外支持的密码套件更安全和简单。

密码套件

TLS/SSL 使用一种或多种密码套件。 密码套件是身份验证、加密和消息身份验证的算法组合。TLS 1.2 版使用的算法存在一些弱点和安全漏洞。在 TLS 1.3 中删除了这些算法：

另外一个很重要的更新是TLS1.3 支持 perfect-forward-secrecy （PFS）算法。

向前保密 （PFS）是特定密钥协商协议的一项功能，如果一个长周期的会话密钥被泄露，黑客就会截获大量数据，我们可以为每个会话生成唯一的会话密钥，单个会话密钥的泄露不会影响该会话之外的任何数据。

TLS在早期版本的握手期间可以使用两种机制之一交换密钥：静态 RSA密钥和 Diffie-Hellman 密钥。 在 TLS1.3 中，RSA 以及所有静态（非 PFS）密钥交换已被删除，只保留了DHE、ECDHE

可以查看网站的安全详情来确认它是否使用"ECDHE"或"DHE"。

AES (Advanced Encryption Standard) 对称加密，它是 高级加密 标准。早期的加密标准DES(Data Encryption Standard) 已被弃用。

AES选择合适的 加密模式 很重要，应用比较多的两种模式 CBC 和 GCM。

CBC 密码分组链接模式

明文分块，第一个块使用初始化向量，后面的每个明文块在加密前与前一个密文块进行异或运算。

这种模式存在的问题：

CTR 计数模式

明文分块按顺序编号，通过加密"计数器"的连续值来生成下一个密钥流块。CTR 模式非常适合在多核处理器上运行，明文块可以并行加密。

GCM 伽罗瓦/计数器模式

GCM = CTR + Authentication。其加密过程，明文块是按顺序编号的，然后这个块号与初始向量 组合并使用块密码E加密，然后将此加密的结果与明文进行异或以生成密文。

简单来说，GCM 是 CTR 身份验证的组合，它更快、更安全。它将接受流水线和并行化实现，并具有最小的计算延迟，所以它的应用更加广泛。

客户端最低版本

客户端最低版本

一般建议同时兼容1.2和1.3

测试是否支持 TLS 1.2

测试是否支持 TLS 1.3

❾ 对于加密的总结（AES,RSA）

跟第三方联调的时候会碰到各种加密算法，所以总结一下。

AES不是将拿到的明文一次性加密，而是分组加密，就是先将明文切分成长度相等的块，每块大小128bit，再对每一小块进行加密。那么问题就来了，并不是所有的原始明文串能被等分成128bit，例如原串大小200bit，那么第二个块只有72bit，所以就需要对第二个块进行填充处理，让第二个块的大小达到128bit。常见的填充模式有

不进行填充，要求原始加密串大小必须是128bit的整数倍；

假设块大小8字节，如果这个块跟8字节还差n个字节，那么就在原始块填充n，直到满8字节。例：块{1,2,3}，跟8字节差了5个字节，那么补全后的结果{1,2,3,5,5,5,5,5}后面是五个5，块{1,2,3,..7}跟8字节差了1个字节，那么补全后就是{1,2,3,...,7,1},就是补了一个1。

如果恰好8字节又选择了PKCS5Padding填充方式呢？块{1,2,3...8}填充后变成{1,2,3...8,8...8}，原串后面被补了8个8，这样做的原因是方便解密，只需要看最后一位就能算出原块的大小是多少。

跟PKCS5Padding的填充方式一样，不同的是，PKCS5Padding只是对8字节的进行填充，PKCS7Padding可以对1~256字节大小的block进行填充。openssl里aes的默认填充方式就是PKCS7Padding

AES有多种加密模式，包括：ECB,CBC,CTR,OCF,CFB,最常见的还是ECB和CBC模式。

最简单的一种加密模式，每个块进行独立加密，块与块之间加密互不影响，这样就能并行，效率高。
虽然这样加密很简单，但是不安全，如果两个块的明文一模一样，那么加密出来的东西也一模一样。

openssl的相关函数：

CBC模式中引入了一个新的概念，初始向量iv。iv的作用就是为了防止同样的明文块被加密成同样的内容。原理是第一个明文块跟初始向量做异或后加密，第二个块跟第一个密文块做异或再加密，依次类推，避免了同样的块被加密成同样的内容。

openssl相关函数：

敲黑板！！ 所以跟第三方对接的时候，如果对面说他们用aes加密，务必对他们发起灵魂三问：

签名的作用是让接受方验证你传过去的数据没有被篡改；加密的作用是保证数据不被窃取。

原理：你有一个需要被验签的原串A。

步骤一：选择hash算法将A进行hash得到hash_a；

步骤二：将hash_a进行加密，得到加密值encrypt_a；

步骤三：将原串A和加密的encrypt_a发给第三方，第三方进行验签。第三方先解密encrypt_a，得到一个hash值hash_a1，然后对原串A使用同样的hash算法进行hash，得到的即为加密前的hash_a,如果hash_a = hash_a1, 那么验签成功。

rsa使用私钥对信息加密来做签名，使用公钥解密去验签。
openssl相关函数：

注意：两个函数中的m，是原串hash后的值，type表示生成m的算法，例如NID_sha256表示使用sha256对原串进行的hash，返回1为签名成功或者验签成功，-1位为失败。

再次敲黑板！！ 所以如果第三方说使用rsa验签，要让对方告知他们的hash算法。

首先明确，私钥加密不等于签名。加密的时候，使用使用公钥加密，第三方使用你的私钥进行解密。
openssl里公钥加密函数为RSA_public_encrypt，私钥解密函数为RSA_private_decrypt，具体的可以自己去查看下官方文档。

rsa也涉及到了填充方式，所以对接的时候也要问清楚

在使用公钥进行加密时，会发现每次加密出的结果都不一样，但使用私钥加密时，每次的结果都一样，网上查了一圈，说是因为填充方式的原因。

官方文档说明：

那么为什么一定要使用私钥做签名，公钥做加密，而不是公钥做签名，私钥做加密呢？
举个栗子：

❿ 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