《key+》如何把密码安全的告诉对方

《key+》是《[data+++]保护个人隐私的安全套装》系列的第三篇，关注FirstLog公众号可以全篇阅读，还有其他你可能感兴趣的创意哈:)

上篇中的用于即时消息流加解密的clip+是离线的，可以离开网络独立运行的；如果你的密码足够复杂且通过其他途径传递不方便的话，加解密的密钥则需要通过网络传输。密钥的网络传输途径很难做到不被破解并监控，我们只能设置足够多的障碍以最大可能的减少入侵者。

我们可以引入PKI系统来达到密钥的保密传输，但完整的PKI系统必须具有权威认证机构(CA)、数字证书库、密钥备份及恢复系统、证书作废系统、应用接口（API）等基本构成部分，构建PKI也将围绕着这五大系统来着手构建。

PKI系统架构图

整个PKI系统架构和配置之庞杂让普通用户望而却步，因此我们不妨采用简化版的仿PKI系统，我们无非就是想传输个密钥罢了，没有那么复杂的。

结合让用户使用便捷的原则，初步整理以下流程：

• 每个用户注册一个账户

• 注册完毕后会在用户本地生成一对公私钥，公钥上传至服务器

• 每个账户可以关联手机号、邮箱、QQ等

• 假设A需要向B发密钥时，输入B关联的任意方式，如手机号或QQ

• A从服务器获取B的公钥，并将要发送的密钥用B的公钥加密后发送给B

• B用自己的私钥解密，并获得A实际发送的密钥

• 当用户需要在多个账户同步时，需要手动在本地转移私钥文件（不通过服务器，以保证数据安全）

• 当用户需要升级密钥时，将上传更新后的公钥，同时服务器提醒用户有哪些设备的私钥失效并通过key+自动更新

我们从使用者的角度上整理一下A和B两位同学通过key+传递密钥的过程：

• A和B分别注册key+账户，并绑定手机号、QQ、微信等

• A有一串密钥“123456”想通过key+发送给B

• A在B中输入B的手机号，找到B，并一键发送密钥

• B收到A发来的密钥“123456”

so easy！和普通聊天在使用上并无任何区别，但却实实在在的保证了密钥没有可恶的小三看到。

服务器的源代码并不复杂，只需要简单的数据库和服务代码。对于企业和小团体用户，只需要拥有一台服务器，而对应的客户端只需要设置对应的服务器资源即可。对于普通用户，则只需要使用公益性的服务器资源即可。

有关key+的赢利方式，可以考虑增加广告投放，毕竟是在线的嘛，但尽量不要影响用户体验；同时付费增值的服务也是可以考虑增加的，比如去除广告、增加提醒渠道等。

=======================

继续为自己代言，公众号FirstLog急需你的关注和建议:)