《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+的贏利方式，能夠考慮增長廣告投放，畢竟是在線的嘛，但儘可能不要影響用戶體驗；同時付費增值的服務也是能夠考慮增長的，好比去除廣告、增長提醒渠道等。