※ 引述《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版本识别字串 一个明码封包, 格式如下 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 但为了第三个步骤的验证, 我建议你可以双方互传一组随机的变数byte array 例如Server传出: FFAAFFAAFFAA Client传出: 001100110011 (每次连线初始化都随机产生) (以SSHv2而言是16个byte的cookie) 3. key exchange 这部分有点杂, 但J2SE有API可以用, 如果你考虑到完整的安全性, 可考虑SSH 的RFC文件 (没记错是4253) 以下S是指Server, C为Client p为一个非常大的质数,心情好的话可以自己选,心情不好就用Second Oakley Group 那个数字很大, 所以麻烦自己去goo一下那个数字, 一大串的16进位用BigInter存 q别管他, 总之q别比p还大 (会怕的话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), Hash function则为SHA-1 以你的case而言H结构双方是要相同的, 且一定要包含步骤2的随机数,及步骤1个 识别字串,其他结构随你心情增减, 这个H最主要用处在於验证你步骤1到3是在跟同一台机器对话 4. S在这个H上用自己的private key来sign, sign完的资讯假设为s 并将刚刚计算出的f, public key, 及签完的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. 计算u2=(rw) mod q 4. 计算v=(((g^u1)(y^u2)) mod p ) mod q 5. 这时候你可以松开你的LP, 比对看看v是不是等於r, 成立则得证, 反之则继续握着LP来debug note:这种计算方法没必要去算v大於r多少, 就算预期s跟实际的s只差1个bit v还是会跟r差距非常地大, 这种比较是没意义的, 只有两种状况: 等於或不等於 没有"差不多"这回事 ok 这个步骤之後, 你就得到一个双方都拥有的share key K, 就用这个K来加密即可 必要的话可以再对这组key做一点处理, 如果要用DES-CBC的话必须用这组key再生出 几组init.用的KEY, 这部份我不是记得那麽清楚了, 所以就不乱唬烂了 以上如果你很有耐心的看完了, 那我相信你有了一点基本的认知, 那你可以开始去找 可以用的API来用, 也不用握着LP写程式 我在手机上run的经验来说, 因为我没建public key认证机制, 所以每次连线都 要重新沟通, 但以实际上机测试效果来说, 顶多delay约3秒而已, 模拟器基本上 也不太会有太严重的delay, 你可以放心的使用, 只要在加解密的演算法上小心点 就好. 另外补充一点, 安全与效能一定是天秤的两端, 就目前的技术而言, 要安全势必会降低部分的效能, 要效能就一定要牺牲掉安全性 很明显的例子就是SSH跟TELNET, 如果ptt大家都用SSH来连, 那势必会造成机器 相当可观的负担. 一点点经验与您分享, 希望能给您一点点帮助, 虽然有点离题XD --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.175.27.54 ※ 编辑: mc18 来自: 218.175.27.54 (03/12 01:11) ※ weii:转录至看板 SFFamily 03/12 15:31 ※ 编辑: mc18 来自: 218.175.27.54 (03/13 00:14)