※ [本文轉錄自 java 看板] 作者: mc18 (無道德事業集團) 看板: java 標題: Re: [問題] 用JCE來加密網路訊息 時間: Wed Mar 12 00:53:47 2008 ※ 引述《prodigywu (Soccer Fever)》之銘言： : 我希望server client彼此互相傳遞訊息前 : 都先將訊息加密傳出去 : 對方收到後再解密 : 但是有點疑惑需要解答 : 我想用JCE的DES來加密 : 那我勢必要把key送給對方 : 可是要怎麼樣才能把key安全的送給對方呢? : 第二個問題是說 : 產生key的過程會很耗時間嗎? : 我的server跟client會大量地互相交換訊息(字串的長度都不會很大) : 如果每傳一個訊息就產生一個新的key : overhead會不會很大呢? : 感謝回答~ 我比較熟SSHv2 你可以考慮他的作法, 也比較多RFC可以啃, 比較不會無聊 首先SSHv2一般來說required的基本加密演算法是用3DES //************************************************************ * * 有鑑於有人問我說3DES跟AES哪一個才是SSH的base encrypion alg. * * 我在這附上RFC4253的部分段落: * * The following ciphers are currently defined: * * 3des-cbc REQUIRED three-key 3DES in CBC mode * blowfish-cbc OPTIONAL Blowfish in CBC mode * twofish256-cbc OPTIONAL Twofish in CBC mode, * with a 256-bit key * twofish-cbc OPTIONAL alias for "twofish256-cbc" * (this is being retained * for historical reasons) * twofish192-cbc OPTIONAL Twofish with a 192-bit key * twofish128-cbc OPTIONAL Twofish with a 128-bit key * aes256-cbc OPTIONAL AES in CBC mode, * with a 256-bit key * aes192-cbc OPTIONAL AES with a 192-bit key * aes128-cbc RECOMMENDED AES with a 128-bit key * serpent256-cbc OPTIONAL Serpent in CBC mode, with * a 256-bit key * serpent192-cbc OPTIONAL Serpent with a 192-bit key * serpent128-cbc OPTIONAL Serpent with a 128-bit key * arcfour OPTIONAL the ARCFOUR stream cipher * with a 128-bit key * idea-cbc OPTIONAL IDEA in CBC mode * cast128-cbc OPTIONAL CAST-128 in CBC mode * none OPTIONAL no encryption; NOT RECOMMENDED ***********************************************************************// 3DES是什麼? 就是DES->DES->DES key拆成三段, 各分給三段的DES去用 (先記得一個原則, DES block size = 8 byte : 64 bits) 好 SSH因為是一種protocol, 設計上會嚴密一點, 流程上或許會有許多你覺得不必要的 你可以自行考慮增減 1. 互丟SSH版本識別字串 一個明碼封包, 其中包含protocol, 版本, 及其他, SSH所使用的識別字串如下: SSH-protoversion-softwareversion SP comments CR LF 這樣可能沒人看得懂, 我舉個例子給您: SSH-2.0-MC18openSSH-v18 just4test <CR><LF> SSH 協定編號 版本名稱及版號 空格 註記 換行(CR LF,可查ASCII表) 2. key exchange演算法溝通 雙方會開始溝通所擁有的演算法及預測對方會使用的演算法, 當然這個步驟在您的 case可以直接跳過, 就假設大家都用Diffie-Hellman key exchange 以及3DES-CBC, SHA-1, DSA 但為了第三個步驟的驗證, 我建議你可以雙方互傳一組隨機的變數array 例如Server傳出: FFAAFFAAFFAA Client傳出: 001100110011 (每次連線初始化都隨機產生) 3. key exchange 這部分有點雜, 但J2SE有API可以用, 如果你考慮到完整的安全性, 可考慮SSH 的RFC文件 (沒記錯是4253) 以下S是指Server, C為Client p為一個非常大的質數,心情好的話可以自己選,心情不好就用Second Oakley Group 那個數字很大, 所以麻煩自己去goo一下那個數字, 一大串的16進位用BigInter存 q別管他, 總之q別比p還大 g可以選2比較保險(如果你選用Second Oakley Group的話) [註]g全名為generator, 以目前的數學技術而言, 沒有一個很明確的方法可以 找出generator, 在一個GF(p)中 (anyway, 你可以無視這句話,總之g別亂選 1. C產生一個隨機數 x ( 1 < x < q)並計算出e=g^x mod p. 並將e發送給S 2. S產生一個隨機數y (0 < y < q)並計算出f = g^y mod p. 3. S收到e之後, 計算e^y mod p, 並產生一個Hash H, 以你的case而言H結構雙方是要相同的, 且一定要包含步驟2的隨機數,及步驟1個 識別字串,其他結構隨你心情增減, 這個H最主要用處在於驗證你步驟1到3是在跟同一台機器對話 4. S在這個H上簽上自己的private key, 並將剛剛記算出的f, public key, 及簽完的sign s一起送給C 5. 在你的case中你可以在C的local database記錄S的public key 在收到S傳來的資訊後, 首先驗證public key是否來自正確的S 6. C計算出共用金鑰K, K=f^x mod p, 並用Server的public key確定sign是否正確 這六個步驟要注意的是, H必須雙方自行紀錄, S在這六個步驟中不會傳H給C C必須自己記錄好整個傳輸過程中的關鍵資訊, 並定義好雙方的格式 (多一個byte都會讓sign差個十萬八千里) 如何用DSA驗證, 我這裡提供一點點演算法, 實際做法可以去goo看看 上述的第4 5步驟中收到的public key(簡寫為K_S)及s分別包括以下內容: s = {p|q|g|y}, 在SSH中屬於mpint, 你可以定義你自己的封包格式 K_S則為一個40byte的憑證資訊(假設演算法為SHA1), 前20個byte為r 後20為s 好了, 再來握好你的LP, 參考一下以下這堆很討人厭的演算法: 1. 計算w=(s)* mod q // *代表inverse 2. 計算u1=(H(m)w) mod q 3. 計算uw=(rw) mod q 4. 計算v=(((g^u1)(y^u2)) mod p ) mod q 5. 這時候你可以鬆開你的LP, 比對看看v是不是等於r, 成立則得證,反之則reject ok 這個步驟之後, 你就得到一個雙方都擁有的share key K, 就用這個K來加密即可 必要的話可以再對這組key做一點處理, 如果要用DES-CBC的話必須用這組key再生出 幾組init.用的KEY, 這部份我不是記得那麼清楚了, 所以就不亂唬爛了 以上如果你很有耐心的看完了, 那我相信你有了一點基本的認知, 那你可以開始去找 可以用的API來用, 也不用握著LP寫程式 我在手機上run的經驗來說, 因為我沒建public key認證機制, 所以每次連線都 要重新溝通, 但以實際上機測試效果來說, 頂多delay約3秒而已, 模擬器基本上 也不太會有太嚴重的delay, 你可以放心的使用, 只要在加解密的演算法上小心點 就好. 一點點經驗與您分享, 希望能給您一點點幫助, 雖然有點離題XD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.175.27.54 ※ 編輯: mc18 來自: 218.175.27.54 (03/12 01:11) -- 三月的柳絮不飛 妳的心如小小的寂寞的城 我達達的馬蹄是美麗的錯誤 我不是歸人 我是馬~ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.132.117.169