柳鲲鹏

仔细对比了代码，发现是循环顺序不一样。一个是从高到低，一个是低到高。我仔细研究了代码，觉得不对。按照我现在的理解，应该都是从高到低。于是反复研究，还是没找到原因。等我写个dump函数查一下。昨天心血来潮，决定写代码，解决密码的有效性。然后就顺便研究一下CDKEY的代码。发现几段类似的代码，就想提取成一个函数。想法是美好的，现实是奇怪的，一改就出错了。其实这是编程中常见的现象。咱不说注释本身对不对，你看明白注释，还不如直接DEBUG看看。我们能做的事情，就是代码要有条理。

世界上第一个研究密码有效位数的人，也许是我？这个没有查过，太阳底下没有新鲜事，应该有人研究过了。如果是我，那真是凭空捡漏了。需要提醒的是， 本源码遵循量子开源协议，有可能向你收费。

　　其实使用gpg也能完成任务。因为看到某个网页有介绍这种方法，于是就记录下。原理图创建私钥# 创建私钥openssl genrsa -out key.pri -f4 2048# 查看私钥openssl rsa -inform PEM -in key.pri -text导出公钥# 导出公钥openssl rsa -inform PEM -outform PEM -in key.pri -out key.pub -pubout# 查看公钥cat key.pub..

前几天开源CDKEY源码，设定自己的密码是“Quantum Office”，然后就想到密码的熵，觉察到目前密码的利用不充分问题。个人感觉应该早就有人讨论过这个问题，如果没有更好，那咱又拿到一个小小的世界第一。那么怎么充分利用密码的熵呢？思路就是进行进制转换，即选择限定的字符，然后转换为7位（128进制）。我们的密码，都是ASCII，就是英文加一些特殊符号。得到密码之后，转换为7位，再作为正式密码。

后来一想这事不对啊，128相当于26的5倍，怎么13位转换后为8位？应该是3位就差不多。于是又仔细研究了代码，没有发现问题；进行了一番正确性测试，也没问题。这几天研究了密码的有效性问题。当时试了一下，13位小写字母的密码，转换为128进制后是8位。

肯定要先配置服务器，这样才能测试。common配置就是服务器的信息。

goto语句之后，不能有新定义变量，必须放在函数开头。这个应该还是编译选项有关。我直接编译是可以的。增加-fpermissive。即使是C++也不行。

开始以为是无法开机启动。长时间后（3-4分钟），又可以登录了。在/etc/hosts中加入自己的IP。想亲自分析代码，没时间，放弃。编辑sshd_config。

意思就是这两个标记不认识，把相应语句注释即可。

注意ssh需要指定的版本。比如我编译libssh-0.11.1，需要的版本是openssl-1.1.1。

只是在编译examples时出错。

我编译时指定了路径，结果系统都提示有问题。

【代码】全网首发：编译libssh，产生类似undefined reference to `EVP_aes_256_ctr@OPENSSL_1_1_0‘的大量错误。

22就是默认的端口。

ssh方便是能上传文件。

【代码】npm ERR!

登录后默认路径是/root；执行命令改为/data；再执行命令发现还是/data。执行命令的channel不能复用，只能执行一次。

我的板子缺少libz.so/libcrypto.so，复制到/lib64下，解决。编译时指定prefix，产生的文件会自带这个目录。编译后的整个目录打包，复制到开发板。可以看到已经启动到后台了。可以使用ssh登录了。

编译/etc/passwd，增加这样一行。

实际上吾并不知道是不是标准的国密SM2。优点就是有一个网站可以验证。本源码也是从别人那边改过来的，已经面目全非了。

具体网站链接在线SM2加密解密,生成公钥/私钥对工具-我现在是越来越糊涂：

合作方要求加密数据。这个我熟，建议使用国密、公钥。我兴冲冲的从网上下载了代码，然后和对方进行联调，双方自己的加密解密都对，一旦让对方解密就错。在网上到处搜索代码，找到了一批代码，神奇的事情就在于，测试结果各不相同！

【代码】国密SM2源码（版本2）（是否标准，存疑）

这个使用的库，是gmssl 3.2.2。搜索3.2.2，找不到相应的代码。这个使用的库，是gm ssl 3.1.1。

同样的密钥，同样的明文，加密结果不同，解密都正确。

【代码】国密SM源码下载及编译。

　　之前同事已经做过一版（吾当时就指点了思路，不听）。做出来的CDKEY实在是太业余，意思就是看着不够乱。　　按理说，这工作已经完成了，头目也满意了，又跟吾无关，吾凑什么热闹？没看到也就算了，既然看到了，看着这样的工作，吾实在是……觉得太可笑，太丢脸……爱管闲事的毛病又来了。怎么办？没有人，而且除了吾别人也没那个能力，所以只能自己亲自搞了。　　很久以前，某同事搞过CDKEY。他自己也很得意，简单的说过流程。他为什么会？因为他以前搞过（应该是从别人接手的，他也确实学会了）。吾亦没在意。对于别人来说工作

具体错误：javax.crypto.IllegalBlockSizeException: Data must not be longer than 117 bytes at com.sun.crypto.provider.RSACipher.doFinal(RSACipher.java:347) at com.sun.crypto.provider.RSACipher.engineDoFinal(RSACipher.java:404) at javax.crypto.Cipher.doFinal

　　既然是CDKEY，肯定要加密。那么使用什么算法呢？首先想到的就是非对称加密，如RCA。为什么呢？因为只要公开公钥，私钥不需要公开啊。试了一下：最短密钥长度512，7个char加密后是64字节。CDKEY一般是5x5、5x6、6x6，64表示起来怎么也得72字节吧？　　如果是证书类，比如许可文件，完全可以使用RSA，因为内容可以长一些，1K都可以。只能使用对称加密。对称加密有个坏处，就是密钥是随产品走的。作为CDKEY，也只能这样了。...

具体代码：package tsoffice;import javax.crypto.Cipher;import java.security.KeyPair;import java.security.KeyPairGenerator;import java.security.NoSuchAlgorithmException;import java.security.PrivateKey;import java.security.PublicKey;import java.securit

代码：package tsoffice;import java.security.Provider;import java.security.Security;public class CheckJCE { public static void main(String[] args) { Provider[] providers = Security.getProviders(); for (Provider p : providers){

测试通过：package tso.system.cdkey;import javax.crypto.Cipher;import java.security.KeyFactory;import java.security.KeyPair;import java.security.KeyPairGenerator;import java.security.NoSuchAlgorithmException;import java.security.SecureRandom;import j

测试通过：package tsoffice;import java.security.Key;import java.security.NoSuchAlgorithmException;import javax.crypto.Cipher;import javax.crypto.NoSuchPaddingException;import javax.crypto.SecretKeyFactory;import javax.crypto.spec.DESKeySpec;public

DES加密时正常，解密时出错了：java.security.InvalidKeyException: Parameters missing at com.sun.crypto.provider.CipherCore.init(CipherCore.java:469) at com.sun.crypto.provider.DESCipher.engineInit(DESCipher.java:186) at javax.crypto.Cipher.implInit(Cipher.java:805)