我的“加密算法”
Lmy (话说名字太长容易被人关注) | 2013-02-27 01:40
Java:
byte[] salt = new byte[512];
new SecureRandom().nextBytes(salt);
MessageDigest digest = MessageDigest.getInstance("SHA-512");
digest.update(password.getByte(Charset.forName("UTF-7")));
digest.update(salt);
1#
safe121 (http://zone.wooyun.org/?do=action&act=thankcontent&id=633) | 2013-02-27 05:14
<?php
function encrypt($str){
return md5(sha1(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(base64_encode(sha1(md5(sha1(base64_encode($str).base64_decode($str)))))))))))))))));
}
?>
2#
顺子 | 2013-02-27 05:19
@safe121 你亮爆了！我草。这加密得多蛋疼和无聊
3#
Lmy (话说名字太长容易被人关注) | 2013-02-27 05:44
@safe121 感谢你的蛋疼
4#
剑心 | 2013-02-27 09:40
这个其实是一个好想法，salt比明文长。这在一定程度上缓解了用户使用弱密码时受到差分密码术攻击的风险。
问题仅仅在于
1. 存储的时候，为了保证一个短小明文的安全，需要保存一个长得多的串。
2. SecureRandom()这个random有经过检验么，或者要满足你使用的安全场景。如果没有，那么很可能更加不安全，更容易受到差分攻击。因为随机数生成算法被爆菊的还是比较多。
5#
sese | 2013-02-27 09:45
@safe121 你亮爆了！我草。这加密得多蛋疼和无聊 +1
6#
剑心 | 2013-02-27 09:47
如果salt太长，而且因为random不好可预测，明文又太短，那么经过初始填充之后，整个消息几乎都是可预测的，这会直接导致sha的前两到三轮过半的结果都是可以预测的，那么只要对后几轮进行差分攻击，结合前几轮的结果，就可以以简单得多的计算量找到冲突或者找到明文。当然理论上是这样的，而且也没有看到过这种“相关明文”或者“部分已知”攻击方面的文章，也可能是这样做没有产出。反正我是sb，这些都只是假大空的理论而已。
7#
O.o | 2013-02-27 09:48
我用了莫尔斯、栅栏、Base64，按不同顺序2道后再MD5
8#
剑心 | 2013-02-27 09:52
@safe121 使用双重散列，会增大冲突的可能性。至于后方使用的多次base64，从密码学的角度来说是没有实际安全意义的。
单向散列函数本质是从一个大集合的明文到一个稍小集合的散列值的单向映射，使用base64，无论多少次，都不可能提高散列值集合的大小。当然从实际的角度，cmd5不可能收录了这么长的明文串的md5
9#
剑心 | 2013-02-27 09:56
@O.o 多次散列的冲突率不低于散列中使用的冲突率最高的那种散列算法。
莫尔斯、base64本质上都是一个单表替换的算法，可以说没有什么安全性可言。何况最后要被套入一个单向散列。还是从密码学意义上说没什么价值，也是防实际攻击而已。
栅栏的话，具体看你怎么做，如果做得不好，那么连多表替换都不是，只是简单的移位。
10#
剑心 | 2013-02-27 10:00
评估一个单向散列算法，就几个方面的因素：
散列是否均匀（冲突率），对输入的敏感度，散列空间的大小，抗差分性，抗线性分析性
在不能自己评估你组合出来的新的单向散列算法在这些方面与原算法的区别的时候，反而不如直接使用多个散列加盐共同验证的方式。不过这样的协议就把宝押在了多个散列里面最次的那一个上。