※ [本文转录自 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