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位有点短
|