公钥算法

HOME RSA 的原理与实现 https://cjting.me/2020/03/13/rsa/ 1976 年以前，所有的加密都是如下方式： A 使用某种规则对信息进行处理 B 使用同样的规则对处理过的信息进行复原 这个方式很好理解，不论是非常简单的 ROT13 还是目前广泛使用的 AES，都是这种对称加密方式。 但是这种方式有一个巨大的缺点，那就是 A 需要将对信息进行处理的规则（也就是秘钥）告诉给 B。怎样安全地传输秘钥就成了一个非常棘手的问题。 那么存不存在一种方式，加密和解密使用不同的秘钥，彻底规避掉传输秘钥的问题？ 答案是存在的，感谢数学家和计算机科学家，RSA 就是这样一种非对称加密方式，也就是： 使用算法可以生成两把钥匙 A 和 B 使用 A 加密的信息，使用 B 可以解开 使用 B 加密的信息，使用 A 可以解开 日常使用中，我们把一把作为公钥，公开发布。一把作为私钥，自己保留。这样，任何人都可以使用我们的公钥加密信息发给我们，我们则可以使用自己的私钥解开。 只要把私钥保存好，这个通信系统就非常安全。 数学原理 现在我们来看看这样一个神奇的系统背后的数学原理。数学作为人类智慧皇冠上最灿烂的明珠，永远是那么的冷静迷人。这里我只陈述内容，具体的证明如果感兴趣可以 Google。 首先我们梳理几个概念。 互质 如果两个正整数，除了 1 以外没有其他的公因数，则他们互质

1. 数据传输分类 在互联网上数据传输有两种：明文传输和加密传输。明文传输的协议有：ftp、http、smtp、telnet。但是为了数据的完整性和安全性，所以后来引用了加密等相关手段来保证数据的安全和完整性。 2. 案例引入 我在外地出差，因工作需要，公司主管要发给我一份重要资料给我，怎么才能让这个资料顺利的传到我的手上，而且我怀疑有人会窃取这个重要资料，若是被谁窃取到那公司损失就大了！ 3. 安全的特点 我能确定这个资料来来自公司 --- 数据来源认证 我能确保在通过因特网传输时没有被修改过 --- 数据的完整性保护（传输的过程中是否被修改） 确宝没有别人能够看到这份资料 --- 数据私密性 （不能被别看到） 主管不能事后否认他曾经发送过那份资料本给我 ---（不可否认性） 4. 角色说明 互联网 黑客 数据 加密 数据 5. 算法 (1). 密码学算法主要分为两个大类，对称加密算法和非对称加密算法，对称加密算法技术已经存在了很长的时间。最早在埃及使用！ (2). 我们很快就能看到，对称加密算法和非对称加密算法各有所长和弱点，所以现代密码系统都在努力做到适当地使用这两类算法以利用它们的长处，同时又避开它们各自的缺点。 6. 对称加密算法的加密和解密原理 对称加密算法概念： 使用相同密钥与算法进行加解密运算的算法就叫做对称加密算法 具体加密过程如下图： 7.

前言 由于业务需要，最近在云上新购买了一批centos7.0的服务器,用脚本批量添加了用户（脚本请见我之前的博客/秘钥认证用户自动控制: http://my.oschina.net/pwd/blog/388254 ）,加完秘钥之后发现,但是secureCRT 抛出了一下异常。 解决过程 ： 1.初步怀疑秘钥有问题,通过命令行去探测是否可以连接,-> ssh -i 秘钥文件 用户名@主机 ，发现能正常连接，确认秘钥是OK的。 2.可能出在secureCRT配置问题，具体操作不详解了,主要是涉及客户端一些可视化的设置,捣鼓完以后没好。 3.根据以上报错联想，可能是这个secureCrt 不支持以上的加密算法，上面已经明确的提示了，于是验证了xshell和putty，以及高版本的SecureCRT是可以连接. 常见终端客户端的介绍请戳链接: http://www.cnblogs.com/276815076/p/4409591.html 由于低版本 SecreCRT 不支持 AES-128-CBC 这个 Cipher，而 Linux 下用 ssh-keygen 生成的公钥默认采用这个 Cipher 的，于是对应的私钥可能会加载不了,所以登陆不上。 思考和学习 参考: http://blog.csdn.net/macrossdzh/article/details/5691924 一

Istio End User Authentication Istio 支持使用 JWT 对终端用户进行身份验证，支持多种 JWT 签名算法，主流的有 RS256/ES256。（也许也会有人用 HS256 做分布式 JWT 认证。。不过这显然是非常危险的） JWK 说明 JWK 全称是 Json Web Key，它描述了一个加密密钥（公钥或私钥）的各项属性，包括密钥的值。 Istio 使用它进行 JWT 验证，因此在使用 RSA 签名算法时，JWK 里提供的应该是用于验证的公钥。 一个 RSA 公钥的数据结构如下： { "alg": "RS256", # 算法「可选参数」 "kty": "RSA", # 密钥类型 "use": "sig", # 被用于签名「可选参数」 "kid": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg", # key id，在有多个 jwk 时(如 jwks 中)被用于区分各 jwk "n": "yeNlzlub94YgerT030codqEztjfU_S6X4DbDA_iVKkjAWtYfPHDzz_sPCT1Axz6isZdf3lHpq_gYX4Sz-cbe4rjmigxUxr

加密工具类： package group.hound.starter.core.util; import java.io.IOException; import java.io.InputStream; import java.io.UnsupportedEncodingException; import java.nio.charset.StandardCharsets; import java.security.*; import java.security.interfaces.RSAPrivateKey; import java.security.interfaces.RSAPublicKey; import java.security.spec.InvalidKeySpecException; import java.security.spec.PKCS8EncodedKeySpec; import java.security.spec.X509EncodedKeySpec; import java.util.Base64; import javax.crypto.*; import javax.crypto.spec.SecretKeySpec; import org.apache.commons.codec.digest.DigestUtils; import org

傻傻分不清楚的kubernetes证书 kubeadm 生成的一坨证书是不是让人很蒙逼，这些东西没那么神奇，来深入扒扒其内裤。 root@k8s-master:/etc/kubernetes/pki# tree . |-- apiserver.crt |-- apiserver-etcd-client.crt |-- apiserver-etcd-client.key |-- apiserver.key |-- apiserver-kubelet-client.crt |-- apiserver-kubelet-client.key |-- ca.crt |-- ca.key |-- etcd | |-- ca.crt | |-- ca.key | |-- healthcheck-client.crt | |-- healthcheck-client.key | |-- peer.crt | |-- peer.key | |-- server.crt | `-- server.key |-- front-proxy-ca.crt |-- front-proxy-ca.key |-- front-proxy-client.crt |-- front-proxy-client.key |-- sa.key `-- sa.pub 1 directory, 22 files 从RSA说起

注意：本节内容主要参考自《Java加密与解密的艺术（第2版）》第8章“高等加密算法--非对称加密算法” 11.1、非对称加密算法 特点： 发送方和接收方均有一个密钥对（公钥+私钥），其中公钥传播，私钥自己保存，不需要传播 私钥不需要传播的特性解决了对称加密算法中密钥传播的困难（这个困难一般通过线下传递可以解决） 加密安全性极高，只用于一些电子商务网站，加解密速度远低于对称加密 一般情况下，为了解决非对称加密算法加解密速度低的问题，采用非对称加密（使用公钥+私钥对对称加密的密钥进行加解密）+对称加密（加解密数据）相结合的方式。 常见算法： DH（非对称加密的基石） RSA（非对称加密的经典，除了可用于非对称加密，也可用于数字签名，RSA--155(512位密钥)已被破解） ElGamal 11.2、DH（仅能用于密钥分配，不能加解密数据） 实现方式： JDK（密钥长度：512~1024中的64的整数倍） 几个概念： 密钥对：公钥+私钥 本地密钥：对称加密的密钥 整个流程： 1）甲乙双方初始化各自的密钥对 甲方构建出密钥对keyPair1-->乙方使用甲方的密钥对中的公钥publicKey1构建出自己的密钥对keyPair2 2）甲乙双方构建各自的本地密钥 甲方使用自己的私钥privateKey1+乙方的公钥publicKey2构建出自己的本地密钥key1

对称加密 ： 发送方和接收方使用同样的密钥。比如DES。 好处：密文长度不受限制。 缺点：不安全 非对称加密： 发送方使用公钥将内容加密，接收方使用私钥将内容解密，比如RSA。 也可以发送方用私钥加密，接收方用公钥解密，这种情况只有一个公钥与私钥对应，应用于数字签名。 好处：密文长度受限制（密文的长度和密钥的长度成正比）。 缺点：相对对称加密比较安全。 混合加密： 集合了对称加密和非对称加密的优点。 比如对称加密的密钥为A。非对称加密的公钥的密钥为B，私钥为C。 发送方：用A对明文进行加密生成m，然后用B将A加密生成n，将m和n混合。 接收方：拆分m和n，用C将n解密得到A，用A将m解密得到明文。 数字签章： 利用hash算法将明文生成固定长度的密文。 数字签名： 数字签名需要达到以下两个目的： 1、对明文进行数字签名后不能被篡改 2、不能否认已经签过的数字签名 签名、解签过程：（说明：私钥m和公钥n是一对非对称加密密钥，并且一个私钥只有一个公钥与其对应） （1）发送方将明文A进行哈希得到h，将h用私钥m加密得到B，并将明文、B一起发送； （2）接收方将接收到的明文进行哈希后得到h1； （3）接收方用公钥n对B进行解密得到h2，如果能解密则就证明一定是发送方签过的，发送方不能否认（因为一个私钥m只对应一个公钥n）； （4）将h1和h2进行对比，如果相同则表示没有被篡改； 过程图：

1 数字证书 1.1 概述 　　数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，数字证书不是 数字身份证 ，而是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名）。它是由权威机构——CA机构，又称为证书授权（Certificate Authority）中心发行的，人们可以在网上用它来识别对方的身份。 2 证书格式 2.1 证书格式分类 分为2大类：密钥库（含私钥，也可能有公钥）和公钥证书（仅含公钥） 2.1.1 密钥库文件格式【Keystore】 格式 : JKS 扩展名 : .jks/.ks 描述 : 【Java Keystore】密钥库的Java实现版本，provider为SUN 特点 : 密钥库和私钥用不同的密码进行保护 格式 : JCEKS 扩展名 : .jce 描述 : 【JCE Keystore】密钥库的JCE实现版本，provider为SUN JCE 特点 : 相对于JKS安全级别更高，保护Keystore私钥时采用TripleDES 格式 : PKCS12 扩展名 : .p12/.pfx 描述 : 【PKCS #12】个人信息交换语法标准 特点 : 1、包含私钥、公钥及其证书 2、密钥库和私钥用相同密码进行保护 格式 : BKS 扩展名 : .bks 描述 :

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