有什么好用的加密软件可以对常用办公文档图纸进行加密？

公司终端、电脑文件数据资料自动智能透明加密，防泄密管理软件系统

支持市面上大部分图纸设计软件，例如 AutoCAD、UG、Pro/E、CATIA、CAXA、SolidWorks、Cimatron、Protel、AI、Photoshop、CorelDRAW、3ds MAX 等。同时，它也支持其他文件的加密保护，支持任意格式文档类型加密，包括Office、Open office、Wps、PDF、outlook、FOXMAIL、ARM、ANSYS、Easypro、OA系统、ERP、MSVISIO、AutoCAD等。

德人合科技——自动智能透明加密防泄密系统主要功能包括文件透明加解密、内部文件流转、密级管控、离线管理、文件外发管理、灵活的审批流程、工作模式切换、服务器白名单等。对于设计院的CAD图纸，该系统可以确保其核心数据随时处于加密保护状态，同时对用户而言完全透明、无感知。

关于如何防止外发合作伙伴二次扩散，德人合科技提供了多种措施。首先，它支持对图纸进行加密，只有经过授权的用户才能打开和查看加密的图纸文件。其次，还支持对外发的图纸文件进行审批和管控，只有符合规定的用户才能将图纸文件外发，同时可以通过设置文件的打开次数、使用时间、密码等限制来进一步控制图纸文件的二次扩散。此外，还支持离线管理，即使员工不在公司网络环境下也能对员工电脑中的文件进行加密和管理，防止数据泄露。

因此，德人合科技图纸加密功能支持多种类型文件，采取了多种措施来防止外发合作伙伴二次扩散。

@德人合科技

————提供软件系统及技术支持

对一个大整数进行因数分解，在高等数学中叫做费马大定理，至今没有被破解

RSA算法是最流行的公钥密码算法，使用长度可以变化的密钥。RSA是第一个既能用于数据加密也能用于数字签名的算法。

这是目前地球上最重要的加密算法

至此，所有计算完成。

将 n和e封装成公钥 ， n和d封装成私钥 。

回顾上面的密钥生成步骤，一共出现六个数字：

这六个数字之中，公钥用到了两个（n和e），其余四个数字都是不公开的。其中最关键的是d，因为n和d组成了私钥，一旦d泄漏，就等于私钥泄漏。

那么， 有无可能在已知n和e的情况下，推导出d？

最终转换成->结论： 如果n可以被因数分解，d就可以算出，也就意味着私钥被破解。

第一步 ：首先生成秘钥对

第二步 ：公钥加密

第三步 ：私钥解密

几个全局变量解说：

关于加密填充方式：之前以为上面这些操作就能实现rsa加解密，以为万事大吉了，呵呵，这事还没完，悲剧还是发生了， Android这边加密过的数据，服务器端死活解密不了， ，这造成了在android机上加密后无法在服务器上解密的原因，所以在实现的时候这个一定要注意

实现分段加密：搞定了填充方式之后又自信的认为万事大吉了，可是意外还是发生了，RSA非对称加密内容长度有限制，1024位key的最多只能加密127位数据，否则就会报错(javaxcryptoIllegalBlockSizeException: Data must not be longer than 117 bytes) ，　RSA 是常用的非对称加密算法。最近使用时却出现了“不正确的长度”的异常，研究发现是由于待加密的数据超长所致。RSA 算法规定：待加密的字节数不能超过密钥的长度值除以 8 再减去 11（即：KeySize / 8 - 11），而加密后得到密文的字节数，正好是密钥的长度值除以 8（即：KeySize / 8）。

爱丽丝选择了61和53。（实际应用中，这两个质数越大，就越难破解。）

爱丽丝就把61和53相乘

n的长度就是密钥长度。3233写成二进制是110010100001，一共有12位，所以这个密钥就是12位。实际应用中，RSA密钥一般是1024位，重要场合则为2048位

爱丽丝算出φ(3233)等于60×52，即3120。

爱丽丝就在1到3120之间，随机选择了17。（实际应用中，常常选择65537。）

所谓 "模反元素" 就是指有一个整数d，可以使得ed被φ(n)除的余数为1。

这个式子等价于

于是，找到模反元素d，实质上就是对下面这个二元一次方程求解。

已知 e=17, φ(n)=3120，

至此所有计算完成

在爱丽丝的例子中，n=3233，e=17，d=2753，所以公钥就是 (3233,17)，私钥就是（3233, 2753）。

实际应用中，公钥和私钥的数据都采用 ASN1 格式表达

回顾上面的密钥生成步骤，一共出现六个数字：

这六个数字之中，公钥用到了两个（n和e），其余四个数字都是不公开的。其中最关键的是d，因为n和d组成了私钥，一旦d泄漏，就等于私钥泄漏。

那么，有无可能在已知n和e的情况下，推导出d？

结论：如果n可以被因数分解，d就可以算出，也就意味着私钥被破解。

可是，大整数的因数分解，是一件非常困难的事情。目前，除了暴力破解，还没有发现别的有效方法。维基百科这样写道

举例来说，你可以对3233进行因数分解（61×53），但是你没法对下面这个整数进行因数分解。

它等于这样两个质数的乘积

事实上，RSA加密的方式原理是一个高等数学中没有被解决的难题，所有没有可靠的RSA的破解方式

一、如何对Webconfig中数据库连接字符串进行加解密，避免明文方式。 1)概述：

WebConfig 中可以存储数据库连接语句，通常存于 <connectionString>配置节中，程序调用非常方便，但是在系统的应用过程中，利用明文存储这些敏感信息是不安全的，这就需要对配置信息进行加密，加密后即使攻击者获取了对配置文件的访问，也可以使攻击者难以获取对敏感信息的访问，从而改进应用程序的安全性。

使用 ASPNET IIS 注册工具 (Aspnet_regiisexe) 加密或解密 Web 配置文件的各节。而在在处理 Webconfig 文件时，ASPNET 将自动解密已加密的配置元素。

要加密配置文件的内容， 通过Aspnet_regiisexe 工具与 –pe 选项以及要加密的配置元素的名称一起使用，利用NET Framework 提供的2种受保护配置程序来实现节点加解密：

名为DataProtectionConfigurationProvider的 DPAPIProtectedConfigurationProvider 实例使用 Windows 数据保护 API (DPAPI) 对数据进行加密和解密。

名为RsaProtectedConfigurationProvider的 RsaProtectedConfigurationProvider 实例使用 RSA 加密算法对数据进行加密和解密。该提供程序配置为默认提供程序

下面就这2中加密方式，分别进行举例如下：

2)使用DPAPIProtectedConfigurationProvider 来加解密配置节

利用aspnet_regiis -pef connectionStrings 对webconfig 加密 在服务器命令提示符下，输入如下命令：

C:\Windows\MicrosoftNET\Framework\v2050727>aspnet_regiis -pef connectionStrings D:\程序\某系统\EpointBid_HuiYuan –prov DataProtectionConfigurationProvider 正在加密配置节„ 成功！

-pef 指定两个参数：

这里 connectionStrings 是要进行加密的配置节，后面是具体的程序路径 这里 D:\程序\某系统\EpointBid_HuiYuan 是要加密的配置文件所在的物理目录。

-prov 表示使用哪个驱动来加密，一共有两个驱动可选，在类似于

C:\WINDOWS\MicrosoftNET\Framework\v2050727\CONFIG 的位置，我们可以找到 machineconfig 文件，在其 configProtectedData 配置节，我们可以看到这两个驱动的名称，以及默认的驱动是哪一个。这两个驱动是 RsaProtectedConfigurationProvider（类名 RsaProtectedConfigurationProvider，详细操作见下说明示例）和

DataProtectionConfigurationProvider（类名 DpapiProtectedConfigurationProvider）。

如果不加驱动选项，则采用默认驱动进行加密。

主要处理证书和印章的验证，以确保签章的合法性。电子签章服务器是对印章卡和个人证书进行合法性验证，确保电子签章的安全性和严密性。主要进行如下几个方面的验证：

电子印章认证模块支持所有客户端电子签章软件进行电子签章时对电子印章的认证，例如支持MS Office、WPS、RED Office、PDF和网页签章时的认证服务。也就是说，不论客户端电子签章采取何种电子签章软件，都可以使用统一的认证服务系统，这样大大提高了系统的整体性和可扩展性，节省了投资。

主要进行以下认证：

a) 数字证书合法性验证：验证数字证书是否由指定的合法颁发机构颁发，如果只是客户端控件，则难以在盖章时就进行验证。

b) 数字证书是否过期：即验证数字证书是否在有效期之内。由于有效的时间必须是服务器端时间，因为依据用户客户端时间来判别证书是否在有效期内是没有任何意义的。

c) 数字证书是否被废止：电子签章服务器会定期从数字证书中心获取废止的证书列表CRL，这样，通过验证证书是否被废止，就可以保证尽管在有效期内，但由于某种原因被废止的数字证书对应的电子印章卡不可以签章。如果没有验证服务器这一点也做不到。

d) 验证电子印章卡或者身份认证卡是否被挂失或销毁：如果说以上几点可以通过公安CA中心提供的服务来完成的话，电子印章卡的状态列表就只有电子印章管理子系统可以产生和发布。因为尽管以上有关数字证书的验证都通过，如果电子印章卡临时遗失、由于电子印章的印模改变而导致电子印章不可再用、或者印章管理中心强制停用某个电子印章，如果签章时不进行验证，所有这些情况都难以鉴别出来，进而会导致不合法的电子签章行为，给电子印章的使用造成混乱。 网页签章服务器端组件的主要功能包含在统一的电子签名认证服务器中了，其主要就是以下两项功能：

a) 验证电子签章（签名）卡以及其中数字证书的合法性；

b) 网页信息的防篡改验证：通过对签名对象的数字签名来鉴别提交的网页信息是否是签名之前的信息。只有验证通过才向数据库中写入数据，否则向客户端报警“网页信息在提交到服务器端时被篡改”。 文件加解密需要服务器端组件与客户端组件结合来完成，服务器端组件主要是实现对客户端提交的加密后的密文进行解密，同时对传递到客户端的文件进行加密。

加解密组件采用数字信封技术实现，数字信封是结合对称密钥和非对称密钥技术各自的优点来实现高效、安全的加解密。

组件首先利用随机对称密钥对文件进行加密，然后再用收件方的公钥加密对称密钥，并将加密后的密钥和密文一起发送到收件人，收件人首先利用自己的私钥解密出对称密钥，再用该密钥解密密文即可获得明文文件。

在实际使用中，有时候根据用途而将对称密钥成为交换密钥。

文件加密解密服务器组件的主要功能包括：

a) 对客户端发送过来的文件进行解密：客户端加解密组件在解决客户端到服务器端的文件传输安全时，对交换密钥进行加密的是服务器证书的公钥，因此，服务器端解密时则采用服务器证书的私钥进行解密以获取交换密钥的明文对密文进行解密。

b) 对发送到客户端的文件进行加密：当客户端访问者需要浏览某个文件时，服务器端组件将利用随机产生的交换密钥对文件进行加密，然后再用收文方的公钥对交换密钥进行加密，将密文与加密后的交换密钥一起发送到客户端。客户端再利用其自身的私钥解密获取交换密钥并以此交换密钥解密密文而获得原文。

目前常用的加密算法主要有：哈希算法（比如MD5、SHA族、Hmac），对称加密算法（比如AES），非对称加密算法（RSA），以及Diffie-Hellman密钥协商算法等等，这几种算法都有各自的特点，适合的场景也不一样，这里只做简单的介绍，想详细了解的话，网上资料很多，可以自行查看相关的资料。

各类算法的特点：

哈希算法：正向快速，不可逆性，即加密后是很难解密出明文的。经常用于数据加密和数据校验。

对称加密算法：AES是一种常用的对称加密算法，其特点是加解密都用同一个密钥。

非对称加密算法RSA：RSA算法是一种非对称加密算法，由一个私钥和一个公钥构成的密钥对，通过私钥加密，公钥解密，或者通过公钥加密，私钥解密。其中，公钥可以公开，私钥必须保密。

Diffie-Hellman密钥协商算法：Diffie-Hellman是一种密钥协商算法（简称DH算法），DH算法基于一种数学原理，能够在双方不泄露密钥的情况下协商出一种密钥来。

在客户端向服务器端发送数据的过程中，如果是比较重要的数据（比如密码，敏感数据等），一般需要先在客户端进行加密后再发送，服务器接收到数据后再进行解密得到原始数据。(反过来服务器返回数据给客户端也是一样的道理)

这里假设客户端和服务器端采用AES（对称加密算法）进行加解密传输的数据，AES加密算法有一个特点就是加解密都用同一个密钥（这里把该密钥称作secretKey），所以双方都通过secretKey进行数据加解密。

因此在客户端向服务器第一次传输数据的时候，客户端需要先向服务器端获取secretKey，并且保存在客户端，而这种直接向服务器获取明文secretKey的过程是很容易被第三者拦截的，也就是说这一过程是不安全的。（哈哈，除非是服务器把secretKey写到纸上，亲手偷偷地递给客户端）

因此呢，客户端向服务器获取secretKey的这一过程，也是需要进行加密的。

那么，服务器需要怎么做才能把secretKey安全的送达客户端呢？

目前常采用的方法有：RSA 或 Diffie-Hellman

RSA有一个公钥和一个私钥，公钥是允许公开出去的，私钥是保留的。RSA的要点在于用公钥加密的数据需要用私钥解密，用私钥加密的数据，需要用公钥解密。因此，比如这时候客户端把公钥发送给服务器，服务器利用客户端的公钥对secretKey进行加密，那么这份加密后的secretKey数据，就只有客户端的私钥能解开啦。即使第三者拿到了这份数据也解密不了，除非能获取到客户端的私钥。

所以，通过RSA的方式，服务器就能把secretKey安全的传递到客户端的手里啦。（不过，RSA也是有安全漏洞的，被称作中间人攻击，由于篇幅原因，这里就先不讲啦！大家自行百度。）

虽然使用RSA能够安全的传输secretKey密钥，但是麻烦点在于需要生成一对公钥和私钥，并且把公钥发送给对方，而且加解密速度比较慢。所以，介绍第二种：Diffie-Hellman密钥协商算法。

严格来说，DH算法其实并不是一种加密算法，因为它本身并不是用于加密的，我的理解是用于双方协商计算，即双方按照某种合约进行计算，从而计算出一种相同的结果。

原理如下：

第一步：初始化

    比如现在服务器提供了两个随机公钥数字（允许公开）：pubN=10，modN=3;

       客户端自己生成了一个随机私钥数字（不可公开，服务器也不知道）：cPrivN=2;

服务器端也自己生成了一个随机私钥数字（不可公开，客户端也不知道）：sPrivN=4;

第二步：客户端、服务器端分别基于相同的数学公式进行计算，计算结果称作公钥结果：pubResult

客户端进行数学计算：cPubResult = pubN cPrivN % modN = 10 2 % 3 = 2；（计算结果允许公开）

服务器进行数学计算：sPubResult = pubN sPrivN % modN = 10 4 % 3 = 1；（计算结果允许公开）

客户端和服务器端交换公钥结果，客户端得到sPubResult=1，服务器端得到cPubResult=2。

第三步：协商出一致的密钥数字:keyN（客户端和服务器端得出的结果是一致的）

客户端：cKeyN = sPubResult cPrivN % modN= 1 2 % 3 = 2；

服务器：sKeyN = cPubResult sPrivN % modN= 2 4 % 3 = 2；

到目前为止呢，双方都协商出了密钥，并且是一致的，但是呢，有没有见过密钥是number类型的？想必都没有吧，所以需要进行第四步，生成更长的密钥。

第四步：对密钥数字进行hash生成密钥串

1、HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。

2、HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。

3、SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

4、TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 10、SSL 20、SSL 30）。

如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS。

1、对称加密

有流式、分组两种，加密和解密都是使用的同一个密钥。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

C++音视频开发学习资料 ：点击 音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

HTTP协议在浏览器/服务器间进行数据的传输是明文的，不做任何的加密，通俗来说，就是“裸奔”，这样会产生什么样的问题那，我们来举一个例子：

在这里插入描述

上述我们通过两个人物模仿了服务器和客户端的交互，我们可以看出，小明和小花之间进行数据通信的时候采用的是明文传输的、那么此时很有可能被中间人获取信息、并进行数据篡改，这种行为就叫 中间人攻击。

所以 HTTP 传输面临的风险有：

（1） 窃听风险：黑客可以获知通信内容。

（2） 篡改风险：黑客可以修改通信内容。

（3） 冒充风险：黑客可以冒充他人身份参与通信。

哈哈、此时你是不是不能很愉快的上网冲浪了呀，别担心，我们此时可以对明文进行加密：

这样是不是比原来安全多了呀！但是这样就足够安全了吗？显然不是的，如果小明和小花在第一次聊天的时候，信息被中间人截取到了，那么中间人是不是也就有密钥了，同样可以对数据进行加解密和修改了那

这可怎么办那？ 加密的数据还是不安全的啊？ 别急，上面我们采用的是对称加密（换句话说就是我们发送的密钥技能加密、也能解密，那么中间人只要拿到密钥消息对他而言就是透明的了），我们还可以采用非对称加密方式进行加密数据(非对称加密一般都会有一个私钥和公钥组成。可以通过公钥加密，私钥解密，也可以通过私钥加密，公钥解密两种方式) ，对密钥的传送在格外加一层保护，当小明和小花在建立通信的时候，小花会把公钥KEY发送给小明，当小明拿到公钥KEY 后，会自己生成一个 密钥 KEY2 , 并用 KEY 对KEY2 进行加密（此时小明用的是公钥加密）

在通信过程中，即使中间人一开始就获取到了公钥KEY ,但是他不知道私钥，就对数据无法进行解密，仍旧是没办法获取KEY2。这样加密后，数据是不是就安全多了呀。这种情况下就可以和妹子愉快的进行聊天了吗？别急、所谓道高一尺魔高一丈，常言道：流氓不可怕，就怕流氓有文化。这种状态下我们的数据，相当来说是比较安全的，但是如果此时中间人获取公钥后，发送给小明一个伪公钥，又会产生什么问题那？

好吧，说到这里，大家是不是快恨死这个中间人了啊，哈哈~~~还有据俗话别忘记了，魔高一尺道高一丈，对于这种情况。我们可以借助与第三方证书平台，证书平台具备产生证书的功能，服务器（小花）可以去证书机构申请证书，证书机构通过小花提供的信息（网址、机构、法人等、公钥），生成公钥和私钥（证书机构的），通过私钥进行数据的非对称加密生成证书、将证书颁发给小花。那么此时小花就可以在进行数据交互的时候，传递证书了。

小明只需要知道证书的发证机构、就可以很方便的获取到证书的公钥、从而对证书进行校验并获取公钥、然后进行后续的操作。

那么此时小伙伴是不是又有疑问了，如果 中间人 获取到证书、并伪造证书给小明、怎么破？？？

不错不错、如果大家有这个想法的话，说明大家都在认真思考了。那么我们假设中间人获取到了证书、中间人也可以在证书机构获取公钥，并通过证书机构公钥获取 服务器发送的公钥，中间人此时也可以自己生成公钥，并向证书机构申请证书、并发送伪证书给小明，但是因为证书是经过签名认证的，包含（网址、机构、法人等、公钥）等信息，小明在拿到伪证书后，通过证书公钥很容易就发现证书是不合法的(网址、法人的信息可定不符，否则申请不到证书的)。

上述我们分享的内容就是HTTPS的主体思想，HTTPS增加了SSL安全层，上述介绍的所有认证流程都是在SSL安全层完成验证的。今天我就分享HTTPS的实现原理就说这么多了。 ﹏

HTTPS 缺点：

（1）SSL 证书费用很高，以及其在服务器上的部署、更新维护非常繁琐。

（2）HTTPS 降低用户访问速度（多次握手）。

（3）网站改用HTTPS 以后，由HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用302跳转）。

（4）HTTPS 涉及到的安全算法会消耗 CPU 资源，需要增加大量机器（https访问过程需要加解密）。