我早就想说这个了，这里的逻辑设计很多都是想当然的设计，业内完全有现成的标准，但是感觉这里就喜欢自造一个。

就拿密钥来说吧，这里的实现就是直接把32 byte以binary形式写入硬盘。.pub以及.priv就是一个纯粹的二进制文件。

业内早已有PEM+PKCS+SPKI这种存储方案，这种解决的并不只是使用起来不方便的问题。也许普通人觉得只是拷贝文本比拷贝二进制方便的问题。但是对于其他程序来说却不是，直接存二进制让人不知所以，其他程序拿到后，必须靠约定俗成来使用（比如约定这32 byte就是Ed25519的密钥），经验之谈，项目搞大了很容易出错，并且时间久了人也有概率搞忘这个文件存的是啥。




PKCS+SPKI几乎是业内通用格式，很多程序都能直接解析使用，跨语言也十分方便。现在密钥的这种binary就是约定方法来使用。之前看了有坛友写的kep-worker就是由于二进制无法直接导入，而被迫使用base64表示。相当于也自造了另一种密钥格式。如果使用PKCS+SPKI统一密钥格式，就不会出现这么多不同语言的分裂问题。


二级签名结构不一定要使用X.509。但是PEM+PKCS#8+SPKI这种通用格式总是要考虑下吧，业内都在兼容openssl的PEM+PKCS#8+SPKI可不只是对程序以及对人来说的友好问题，对于项目复杂化后，统一密钥管理也是个问题。

其他的不说，就单说密钥文本化表示我也支持。每次用二进制格式拷贝都得scp过去感觉挺麻烦的。另外bin也不能直接存密钥管理器里面。

就连自造格式的openssh key的存储方案也是密钥文本化表示，密钥文本化感觉真的很必要啊

确实，我也感觉密钥文本化表示是一个必要功能。我接触的币圈的大多数钱包也是搞文本化表示。真正密钥也一样是bin私钥的，但是都不约而同的密钥文本化，甚至还搞助记词

@nicepig(ecineo) 这种是当然的了，二进制存的密钥容易搞丢啊，别问我怎么知道的

先纠正一点，PEM+PKCS+SPKI并非一套格式。准确来说是PEM封装PKCS+SPKI。负责文本化的应该是外层的PEM封装。而后面的PKCS+SPKI应该是结构化的。

如果只想文本化包一层PEM封装就够了。楼主提出的是格式化方案。文本化只是PEM的副作用罢了。

@bigjj(pjeigl) 二进制格式的密钥就是不好存，先不说密码管理器，单单是导入与备份都不方便

pkcs#8我也觉得是一个很臃肿的格式，但是很多时候我也无可奈何。很多工具导入就只支持pkcs#8格式的私钥，你不想用也得用。

生活就像强奸，即使被迫习惯了也不要把强奸看作理所当然。什么"存在即合理"我都看腻了。

感谢各位的建议。旧方法直接存bin是当初需要跑起来而图方便而已。

我也看了下包括ssh/wg在内的很多非X.509系列密钥也几乎都搞文本化编码的。





打算重新设计了一个全面密钥格式体系，就参考你们讨论的了。

外层使用PEM封装，以文本化表示。公钥使用：PEM+SPKI。私钥使用：PEM+RAW。

然后再兼容旧格式读取，各位觉得这种设计还有没有什么意见要提的。




PKCS#8我看了下历史兼容包袱比较多，搞得比较复杂。那么就PEM+RAW编码私钥了？

@sky.stalltrix.com 我能厚颜无耻的提一个建议吗？生成密钥的时候，能不能顺便把base64也输出来。最近都在使用坛友的kep-worker，这个程序依赖base64格式密钥。

openssl 或者certutil 再转换一遍太麻烦了，并且很多系统上不一定有这两个工具。

@skymmap(ev3tup) 感觉没啥问题，KCS#8我也看了下确实历史兼容包袱很多，搞复杂了就是容易出现问题。

想了下私钥就是给自己用的，没必要做成复杂的通用格式以交换给别人。而公钥PEM+SPKI就是标准格式，这点交换给别人也没啥问题

新密钥格式没啥问题，只要不搞成breaking change就行

Ok了，新密钥格式的beta实现已经设计完成了，分别是kepweb的commit 8bea3d6以及kep-cli的commit 9220dc8。




另外，@2077朋克(nqcpjw) 提出的cli自动生成base64格式也顺便加上了。gen的时候，会输出genkey.log文件，里面有mainkey、pkey 、signkey的base64。出于安全考虑，里面没有private key的base64。

private key的base64可以直接打开pkey.priv文件，PEM+RAW编码中间的值就是base64。

---

kep-cli commit 9220dc8版本及以后默认生成的key是新格式，需要旧格式的手动使用`./kep-cli gen -req=raw`的`-req=raw`参数指定。

@BitForge(xxqeir) 你好像搞混淆了一个概念，公钥确实是交换给别人的。但是并不是以标准的PEM+SPKI格式交换给别人。而是直接以数据形式交换给别人。

PEM+SPKI格式是存储形式

哈哈，标准哥每次发言就是牛逼。一开口就能说出什么“标准”，“已有方案”，“成熟实现”等宏大建议。一看就是当项目领导的料

@duso(nk6eqj) 卧槽老哥怎么又给人乱取外号了，我记得上次也给别人取“漏洞王”，上次帖子还在这里呢

啊，怎么只实现了一半。公钥SPKI封装变成了标准的了，私钥是自定义格式。这种感觉挺奇怪的啊，由于程序必须同时读取公钥与私钥才能运行。这种兼容一半与完全不兼容没有区别。相反程序还必须处理两套格式，这种新设计又是什么奇葩设计？

@hua(gk2s6c) 你懂什么，这种实现可是远超端水大师的折中智慧




在你说这话之前，PEM+SPKI+RAW方案。解决了楼主的半个通用格式。2、3、4、6楼的文本化问题。7楼的pkcs#8臃肿问题。11楼的免breaking change问题。也顺便解决了9楼的其他需求。这折中水平连禅师来了也得拜师。

@hua(gk2s6c) 要不你来写一版？写完后提pr或者发patch到邮箱都行

@skymmap(ev3tup) 可以，看了下应该只用修改keyencode包对象的解析函数与生成函数就行。写好了发给你

改了几版patch终于被合并了，使用`-req=pkcs`指定可以生成PKCS#8的私钥。实现了标准的PKCS#8私钥的生成与解析。至此已完全支持标准的PEM+PKCS#8+SPKI格式。

不过默认生成还是PEM+RAW+SPKI格式，除非手动指定`-req=pkcs`，多次交流后妥协的结果。。。不过解析函数三种格式都能识别。