
1 eric_zyh OP 有现成的方案更好了。。求帮助 |
2 skywinger 2011 年 12 月 5 日 用个des或是rsa算法不就搞定了? |
3 issac 2011 年 12 月 5 日 MD5不行? 要是偏移的话 可以用706 << 10; |
4 CoX 2011 年 12 月 5 日 zend? 得通过组件解密吧,如果自己加密自己解密,就没啥意义了。 |
5 skywinger 2011 年 12 月 5 日 @issac MD5/SHA1等HASH签名算法不是加解密算法,只是计算一个散列值数字签名而已,因此数字签名不能够反向计算出原先的明文。 可以使用DES或是RSA这类的加解密算法来加解密关键数据。 |
6 eric_zyh OP |
8 miao 2011 年 12 月 5 日 |
9 CoX 2011 年 12 月 5 日 |
10 Hyperion 2011 年 12 月 5 日 干什么用的? 密钥固定嘛? 可以考虑自己弄一个高次方程, 带入... |
19 skywinger 2011 年 12 月 6 日 @CoX 我也不是做PHP的,但是我接触加解密体系这块比较多,我是做金融终端设备接入系统的,接触很多金融安全级别的加解密体系,DES、RSA、mac计算等等。 |
20 eric_zyh OP |
22 skywinger 2011 年 12 月 6 日 |
23 myrual 2011 年 12 月 6 日 @skywinger 多谢指导。我才知道原来我们总用的这个PBOC是怎么来的。 其实PBOC用到了算法。他使用的是3des。只不过是两次而已。 银行领域还在使用des 3des么?不是说已经不够安全了么? |
24 arzon 2011 年 12 月 6 日 要保证加密后的结果是定长, 那怎么能解密?? |
25 skywinger 2011 年 12 月 6 日 @myrual 需要保证安全的话,就需要使用硬件加密,尽量不采用软加密,另外计算数字签名mac值,mac算法由具体的金融机构定制。另外金融交易报文多采用ISO8583报文规范。 |
28 skywinger 2011 年 12 月 7 日 对的,基本都是ISO8583报文格式。 手机支付是基于8583基础上的XML报文。 |
29 sharmy 2011 年 12 月 22 日 定长就不好搞了吧,而且10位有点短 |