数字签名

信息的加密现有两种 对称加密：使用同一个密钥对信息进行加密和解密称为对称加密。 使用场景：A与B共同约定并存储一个密钥。 A -> B： A 使用密钥对数据进行加密后得到加密的信息发送给 B，B 使用该密钥对加密的信息进行解密，得到原始信息。 B -> A： B 使用密钥对数据进行加密后得到加密的数据发送给 A，A 使用该密钥对加密的数据进行解密，得到原始数据。 优点：加密解密速度快。 缺点： 相对不安全，由于 AB 双方使用的是同一个密钥进行加密解密，任何一方的密钥泄漏，整个加密解密过程就暴露了。 在与多方进行通信的时候必须使用不同的密钥，多个密钥造成密钥管理困难。如果 A 与 B 通信时和 A 与 C 通信时使用的是同一个密钥，那么如果 C 获取到了 A 与 B 通信时加密的信息就可以使用密钥进行解密，造成 A 与 B 之间信息的泄露。 非对称加密：加密和解密使用不同的密钥。如果加密使用的是公钥，那么就必须要私钥来解密。如果加密使用的是私钥，必须要公钥进行解密。在此需要先了解公钥、私钥这两个概念。 公钥：供给别人使用的密钥，使用公钥对信息加密的过程称之为加密，主要目的为防止信息传输过程中的泄漏。因为用于解密的私钥只有自己拥有。 私钥：供给自己使用的密钥，使用私钥对信息加密的过程称之为签名，主要目的是为了确保信息是由自己发出的

基于Postman 6.1.4 Mac Native版 演示结合 user_api_demo 实现 PS 最近接到任务, 要把几种基本下单接口调试和持续集成一下, 做个常规功能验证, 研究了下发现, 不同的下单途径, 有的需要登录(Session依赖), 有的需要验签(使用数字签名的微服务), 接口中依赖很多动态数据, 如用户id, 地址id, 工单id, 当前时间等等, 而且最重要的一点, 下单接口是异步的, 只返回事件流event_key, 特别在测试环境上, 订单处理比较慢, 需要对结果进行一个较长时间的轮询, 在选型时候, 最开始觉得, 异步接口结果轮询只能用Jmeter的定时器实现, 然而个人实在不太习惯Jmeter的元件组织逻辑(拆分过碎). 遂尝试用JS + Postman进行实现. 可行性 新版Postman 增加了Pre-request Script和Test, 使用Javascript, 并且支持Collection(测试集合)/Folder(子测试集) 级别(如下图), 功能类似与其他测框架的setUp和tearDown, 相当于具有了Fixtures功能, 可以针对不同的Scope(范围)来进行准备和断言及清理. Postman支持的JS脚本库 Lodash: 一套JS实用的方法库, 封装了很多String, Array, Object等的处理方法,

转载自： https://blog.csdn.net/zyhlwzy/article/details/77946086 由于计算机软件的非法复制，通信的泄密、数据安全受到威胁，解密及盗版问题日益严重，甚至引发国际争端，所以在信息安全技术中，加密技术占有不可替代的位置，因此对信息加密技术和加密手段的研究与开发，受到各国计算机界的重视，发展日新月异。现在我们就几种常用的加密算法给大家比较一下。 DES加密算法 DES加密算法是一种分组密码，以64位为分组对数据加密，它的密钥长度是56位，加密解密用同一算法。DES加密算法是对密钥进行保密，而公开算法，包括加密和解密算法。这样，只有掌握了和发送方相同密钥的人才能解读由DES加密算法加密的密文数据。 DES算法的入口参数有三个：Key、Data、Mode。其中Key为8个字节共64位，是DES算法的工作密钥；Data也为8个字节64位，是要被加密或被解密的数据；Mode为DES的工作方式，有两种：加密或解密。 DES算法是这样工作的：如Mode为加密，则用Key 去把数据Data进行加密， 生成Data的密码形式（64位）作为DES的输出结果；如Mode为解密，则用Key去把密码形式的数据Data解密，还原为Data的明码形式（64位）作为DES的输出结果。在通信网络的两端，双方约定一致的Key，在通信的源点用Key对核心数据进行DES加密

先粗略解释一下： 一、公钥加密 假设一下，我找了两个数字，一个是1，一个是2。我喜欢2这个数字，就保留起来，不告诉你们(私钥），然后我告诉大家，1是我的公钥。 我有一个文件，不能让别人看，我就用1加密了。别人找到了这个文件，但是他不知道2就是解密的私钥啊，所以他解不开，只有我可以用数字2，就是我的私钥，来解密。这样我就可以保护数据了。 我的好朋友x用我的公钥1加密了字符a，加密后成了b，放在网上。别人偷到了这个文件，但是别人解不开，因为别人不知道2就是我的私钥，只有我才能解密，解密后就得到a。这样，我们就可以传送加密的数据了。 二、私钥签名 如果我用私钥加密一段数据（当然只有我可以用私钥加密，因为只有我知道2是我的私钥），结果所有的人都看到我的内容了，因为他们都知道我的公钥是1，那么这种加密有什么用处呢？ 但是我的好朋友x说有人冒充我给他发信。怎么办呢？我把我要发的信，内容是c，用我的私钥2，加密，加密后的内容是d，发给x，再告诉他解密看是不是c。他用我的公钥1解密，发现果然是c。 这个时候，他会想到，能够用我的公钥解密的数据，必然是用我的私钥加的密。只有我知道我得私钥，因此他就可以确认确实是我发的东西。 这样我们就能确认发送方身份了。这个过程叫做数字签名。当然具体的过程要稍微复杂一些。 用私钥来加密数据的摘要，用途就是数字签名。 总结：公钥和私钥是成对的，它们互相解密。 公钥加密

RSA数字签名算法主要可以分为MD系列和SHA系列两大类。 MD系列：MD2withRSA、MD5withRSA。 SHA系列：SHA1withRSA、SHA224withRSA、 SHA256withRSA 、SHA384withRSA、SHA512withRSA。 package com.antfin.jdk8.sign; import java.security.*; public class SHA256withRSA { private static final String KEY_ALGORITHM = "RSA"; private static final String SIGN_ALGORITHM = "SHA256withRSA"; private static final String ENCODING = "UTF-8"; private static final int KEY_SIZE = 2048; public static void main(String[] args) throws Exception { String data = "待签名的数据"; KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(KEY_ALGORITHM); keyPairGenerator

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u010324331/article/details/85268130 首先 需要安装扩展 xmlseclibs 地址： https://github.com/robrichards/xmlseclibs 然后 看下面示例（github上面也有测试的调用示例） /** * generateXMLSignFields XML生成签名域 * Use sha256withrsa algorithm to generate XML internal signature * @param $xml * @return string * @throws \Exception * @author liuml <liumenglei0211@163.com> * @DateTime 2018/12/21 16:37 */ protected function generateXMLSignFields ( $xml ) { // 加载要签名的XML $doc = new \ DOMDocument ( ) ; $doc - > loadXML ( $xml ) ; // 创建一个新的安全对象 $objDSig = new XMLSecurityDSig ( ) ; // 使用c14n专属规范化

密码学基础总结 1.安全通信要解决的问题 1.窃听 2.欺骗 3.伪造 4.否认 2.解决 1.加密 2.消息认证码或者数字签名 3.消息认证码或者数字签名 4.数字签名 3.数字证书用来解决公钥持有人无法识别的问题 1.电子密码本模式ECB 2.密码链模式CBC 3.密文反馈模式CFB 4.输出反馈模式OFB 5.计数器模式CTR 1.对称加密不能解决的问题 1.钥匙交付问题 2.非对称加密不能解决的问题 1.加密和解密的时间都比对称加密所需要的时间要长 2.公开密钥的可靠性 3.混合加密 1.用来解决密钥交付问题和加密时间长的问题 2.ssl采用的是混合加密的方式 4.数字证书系统 1.可以保证公钥创建者 5.diffle-hellman密钥交换 1.用来解决密钥交换问题 6.消息鉴别码 1.用来实现认证和伪造检测 7.数字签名 1.用来解决防否认的问题 2.不能解决公钥创建者认证问题 1.什么是对称加密 1.加解密钥相同 2.能干什么 1.比非对称加密效率高 3.怎么用 1.加密算法 1.des 1.不安全 2.密钥8byte 3.分组加密，每组8字节 2.3des 1.安全效率低 2.密钥8*3 3.分组长度8byde 3.aes 1.安全，效率高 2.密钥16，32，64字节 3.分组长度16字节 2.分组模式 1.ecb,不安全，不推荐 2.cbc,安全 3.cfb

keytool 是安全钥匙和证书的管理工具。他管理一个存储了私有钥匙和验证相应公共钥匙的和他们相关联的x.509 证书链的keystore(相当一个数据库)。 keytool 是个有效的安全钥匙和证书的管理工具。 他能够使用户使用数字签名来管理他们自己的私有/公共钥匙对,管理用来作自我鉴定的相关的证书,管理数据完整性和鉴定服务。他还能使用户在通信时缓存他们的公共钥匙。 一个证书是某一实体(个人,公司等)的数字签名,指出其他实体的公共钥匙(或其他信息)的周详的值。当数据被签名后,这个签名信息被用来检验数据的完整性和真实性。完整性指数据没有被修改和篡改,真实性指数据从所有产生和签名的一方真正的传输到达。 keytool 把钥匙和证书储存到一个keystore。默任的实现keystore的是个文件。他用一个密码保护钥匙。 而另外的一个工具jarsigner用keystore中的信息产生或检验java archive(jar文件)中的数字签名。 keystore有两个不同的入口: 1.钥匙入口:保存了非常敏感的加密的钥匙信息,并且是用一个保护的格式存储以防止未被授权的访问。以这种形式存储的钥匙是秘密钥匙,或是个对应证书链中公有钥匙的私有钥匙。 2.信任证书入口:包含一个属于其他部分的单一公共钥匙证书。他之所以被称为"信任证书"

一、数字签名简介 数字签名过程的一般模型： 在收发双方不能完全信任的情况下，需要除认证之外的其他方法来解决他人伪造或当事人否认的问题。 数字签名是解决这个问题最好的方法。 数字签名必须具有的特征： 验证签名者、签名日期和时间（ 消息来源 ） 认证被签的消息内容（ 数据完整性 ） 签名由第三方仲裁以解决争执 数字签名具有认证功能。 攻击： 伪造： 数字签名应满足的条件： 直接数字签名： 只涉及通信双方（发收双方）的数字签名方案 假定接收方已知发送方的公钥，用共享的密钥（对称密码）对整个消息和签名加密，则可以获得保密性 先进行签名，再执行外层的加密，在发生争执时，第三方可以查看消息及签名。 该方法的有效性依赖于发送方私钥的安全性。 二、数字签名算法（DSA） 使用安全Hash算法（SHA），最新版本还包括基于RSA和椭圆曲线密码的数字签名算法。 两种数字签名的方法： DSA使用的是只提供数字签名功能的算法，与RSA不同，DSA虽然是一种公钥密码方案，但不能用于加密或密钥交换。 在RSA方法中，Hash函数的输入是要签名的消息，输出是定长的Hash码，用发送方的私钥将该Hash码加密成签名，然后发送消息及其签名。接收方收到消息，计算Hash码。接收方用发送方的公钥对签名解密，如果计算出的Hash码与解密出的结果相同，则认为签名是有效的。因为只有发送方拥有私钥

本篇是iOS逆向开发的递进篇-关于哈希算法、数字签名及对称加密等，下面我们着重讲解此内容，希望对大家有所帮助！！！ 一、哈希 1.1 基本内容 哈希表也称为散列表（Hash table），是根据关键码值（key，value），直接进行访问的数据结构。通过把关键码映射到表中的一个位置来进行访问记录，用来加快查找速度。映射函数也称之为散列函数，存放记录数组称为散列表。 假设没有内存限制，直接可以将键作为数组的索引，那么所有的查找仅仅需要一次即可完成。但是这种理想的情况也不会一直出现，因为牵扯到内存问题。从另一个角度来说，如果没有时间来限制，我们也可以使用无序数组并进行顺序查找，这样也会使用较少的内存。 使用哈希查找算法分为两个步骤： 使用Hash函数将被要查找的键转化为数组中的一个索引。理想情况下，不同的键都可以转为不同的索引值。但这仅仅是理想情况下，在实际的开发运算中，我们还是要处理两个或者多个键值散列到同个索引值的情况。 要处理碰撞冲突的过程。 目前本人博客关于讲述哈希思想查找元素的博客有： https://www.cnblogs.com/guohai-stronger/p/11506990.html ，还会持续更新此类算法思想有关的题目。 1.2 哈希函数的两种解决碰撞的方式 1.2.1 拉链法（separate chaining） 拉链法简单说就是链表+数组