中国分布式计算论坛

 找回密码
 新注册用户
搜索
楼主: Youth

[项目新闻] [BOINC] [数学,算法类] DistrRTgen

[复制链接]
发表于 2008-11-29 20:44:26 | 显示全部楼层 |阅读模式
http://boinc.freerainbowtables.com/distrrtgen/

建议大家不要参加这个项目,原因见本主题5楼。

The goal of FreeRainbowTables.com is to prove the insecurity of using simple hash routines to protect valuable passwords, and force developers to use more secure methods.

网站的目的是证明用简单哈希函数来保护有价值的密码是不安全的,并促使开发人员使用更为安全的方法。

By distributing the generation of rainbow chains, we can generate HUGE rainbow tables that are able to crack longer passwords than ever seen before.

利用分布式计算,我们可以生成巨大的rainbow table,然后就可以破解那些以前没法破解的更长的密码。

Furthermore, we are also improving the rainbow table technology, making them even smaller and faster than rainbow tables found elsewhere, and the best thing is, those tables are freely available to download from our site!

更进一步,我们也在改进raibow table技术,使之比其它地方的rainbow table更小更快,而最棒的事情是,这些tables将可以从我们的网站上自由的下载!

By installing and running the BOINC client available from our download page, you can help us to speed up the generation even more.

通过安装和运行boinc客户端,你将能够帮助我们加速rainbow table的生成!

For more information, see www.freerainbowtables.com

更多信息请查看我们的网站。

///

之前也有过一个或多个关于rainbow table的项目,比如已经结束的那个TMRL DRTG。

///

不太了解这方面的技术,rainbow table有什么常用的中文名吗?

评分

参与人数 1基本分 +30 维基拼图 +15 收起 理由
霊烏路 空 + 30 + 15

查看全部评分

 楼主| 发表于 2008-11-29 20:46:01 | 显示全部楼层

Nov 26, 2008

DistrRTgen is finally out of beta and is now in production mode! Let the race to the top begin!

项目结束测试阶段,正式运行!

评分

参与人数 1基本分 +10 维基拼图 +3 收起 理由
霊烏路 空 + 10 + 3

查看全部评分

发表于 2008-11-29 21:15:12 | 显示全部楼层
搜索了一下,暂未发现常用中文名。
有些东西,可能用 英文 表示要比翻译还好一些

http://www.twisc.ncku.edu.tw/epaper/13/column.htm

Rainbow table是一種資料結構表,用預先計算的方式產出一些值,再利用這些值進行破解運算,Rainbow table即是指這個預存資料的表,通常要數十至數百G,Table大小關係到破解時間長短,目前國外有公司在販賣他們算出來的表,網路上也有免費可供下載的表(多數不超過20g,相對較小),Rainbow table目前多用在分散式運算破解方面。


參考網頁
wikipedia
http://en.wikipedia.org/wiki/Rainbow_table




https://www.xfocus.net/bbs/index ... =65440&view=old

  1. Rainbow Table 是由Philippe Oechsilin在Making a Faster Cryptanalytic Time-Memory Trade-Off中提出的一种改进型的PreComputering Table. 主要目的是为了提高成功率, 并且减少存储空间.
  2. 1. Rainbow Table的组织和生成(rtgen说明)

  3. Rainbow Table 是由很多16bytes的RainbowChain组成的.

  4. RainbowChain的结构如下:
  5. struct RainbowChain
  6. {
  7. +000 uint64 nIndexS;
  8. +008 uint64 nIndexE;
  9. };

  10. rainbowTable的数量是由字符空间决定的, 事先计算好再由argv[7]传入.
  11. int nRainbowChainCount = atoi(argv[7]);

  12. nIndexS由函数cwc.GenerateRandomIndex()随机生成( 这样生成是有目的的, 将在后面解释 )
  13. 与此同时这个index也被放入了CChainWalkContext.m_nIndex中, m_nindex启到中间记录作用
  14. nIndexE经过nRainbowChainLen次计算而来的.

  15. 整个过程如下:

  16. 1) 将随机生成m_nindex(开始即nIndexS)通过cwc.IndexToPlain() 见[1]得到由字符空间定义表示字符
  17. 整个转换过程和二进制转16进制差不多, 只不过变成了明文字符长度进制(m_nPlainCharsetLen)

  18. 2) 对步骤1得到字符进行预先设定的HASH函数 - cwc.PlainToHash()

  19. 3) 对生成的HASH进行Reduce, 在此Reduce函数为cwc.HashToIndex(nPos) 见[2]
  20. 最后得到的m_nindex还是必须规定在字符空间的范围内( .'. % m_nPlainSpaceTotal).

  21. 将上面三步重复nRainBowChainLen次后, 将m_nindex放入到nIndexE中. nRainBowChainLen就是Chain长度.
  22. 并且所有的RainbowChain均是重复上述步骤.

  23. 也可以表示成如下过程:

  24. PLAIN HASH Reduce
  25. K1 -------> C -------> H --------> K2 ----->....

  26. index plain hash reduced hash
  27. (new index) <----- 减少存储空间的关键

  28. 由于在整个过程中会产生新的index, 虽然并不记录, 但还是可以推算得到的, 因为所有函数都是单向的.
  29. 所以严格按照排列生成 nIndexS就变得没有必要了. 这些新的index很可能就已经包括在内了, 当然这些
  30. 新的index会有一定reduce范围, 这是由m_nReduceOffset造成的. 成功率的概念也是由于这个原因, 很可能
  31. 整个Random的过程并没有覆盖到每一个排列, 增加多张同一个ReduceOffset表的目的也是为提高覆盖率, 但是
  32. 还是会有miss率, 哪怕是0.01%甚至更小.

  33. 根据Philippe Oechsilin的Paper中将 K1 -> K2 的过程定义为fn, 而fn不同原因主要在于Reduce函数不同
  34. (造成这中不同的原因在于nPos的增加 见[2])

  35. 2. Rainbow Table的排序(rtsort的说明)

  36. rtsort 使用了快速排序 和 外部排序
  37. 排序的对象就是 RainbowChain.nIndexE, 这一点需要十分注意.

  38. 外部排序只有在内存容量很低的时候, 才会采用.

  39. 外部排序的过程:

  40. 1) 根据内存的大小从rainbow table文件中读取相应的大小的内容.

  41. 2) 使用快速排序将相应的chain进行排序, 存放到temp文件中.

  42. 3) 相应的信息存放到CSortedSegment结构的链表中

  43. 4) 重复上述1-3步, 直到读取完rainbow table的所有内容.

  44. 5) 将链表中的所有的项进行归并.(并非使用二路归并, 而是一起归并)
  45. 归并从所有的经过排序的项中取最小的一个, 排序的对象是 RainbowChain.nIndexE , 后8个字节

  46. +++---
  47. 此时还作了一些优化:

  48. GetNextChain会预先在文件中读取m_nFileChainCount放到RainbowChain.m_chain[]的数组中.
  49. 但大小超过1024, 也只读取1024.
  50. if (m_nChainCount == m_nNextChainIndex) 是一个判断 可能进行下一次读取的条件
  51. 返回m_nNextChainIndex指向的m_chain[m_nNextChainIndex]的地址(RainbowChain *)

  52. RemoveTopChain 主要作用就是 更新m_nNextChainIndex, 但全部读完后, 返回true, 让MergeSortedSegment删去该链项(list.erase)
  53. ---+++

  54. 6) 将归并后的项放入原来的文件中.


  55. PrepareSortedSegment函数 过程 1 - 4
  56. MergeSortedSegment 函数 过程 5 , 6

  57. 3. Rainbow Table的使用(rcrack的说明)

  58. 更应该说rcrack的过程就是查表的过程.

  59. 1) 针对每个rt文件进行搜索
  60. for (i = 0; i < vPathName.size() && hs.AnyhashLeft(); i++)
  61. {
  62. SearchRainbowTable(vPathName[i], hs);
  63. printf("\n");
  64. }

  65. 2) 在SearchRainbowTable中根据内存大小, 分成一块块的进行Search.
  66. 调用SearchTableChunk函数.

  67. 3) 以下为rcrack的关键函数

  68. SearchTableChunk(pChain, nRainbowChainLen, nRainbowChainCountRead, hs);

  69. pChain - 存放在内存中Rainbow Table的Chain表, 可能Rainbow Table中的项要比内存大得多,
  70. 所以用CMemoryPool实现根据内存大小分配空间. pChain使用CMemoryPool.Alloc分配的.

  71. nRainbowChainLen - RainbowChain的长度

  72. nRainbowChainCountRead - 读入pChain中RainbowChain的数量, 读入文件大小/16 (当然必须是16的倍数)

  73. hs - 存放将要检验的HASH, 并且还要存放Crack的结果, 是否发现原始HASH, 是否发现, 明文等等.
  74. //++
  75. vector<string> m_vHash;
  76. vector<bool> m_vFound;
  77. vector<string> m_vPlain;
  78. vector<string> m_vBinary;
  79. //--

  80. 整个查表过程如下
  81. a. 首先作一些准备工作
  82. HASH的设置,转换之类的工作
  83. RequestWalk的目的是为某个需要破解的HASH, 生成一个存放用于匹配pChain[i].nIndexE的数组.
  84. RequestWalk会在第一次时创建, 会根据Chain的长度和相应Pos的位置计算好所要匹配的项. (见[4-1])
  85. 只需按Pos的位置定义, 所以只需再开始时计算一次, 以后该HASH的计算均可使用.

  86. b. 计算过程和比对过程
  87. 第一次将HASH使用nPos位置的Reduce函数(Rn-1 n为ChainLen), 与pChain[i].nIndexE中的所有项相比较.
  88. 若找到了相匹配的值, 则使用CheckAlarm函数来进行检验. CheckAlarm根据猜测的所在位置, 从nIndexS
  89. 开始推, 重复f函数的步骤, 到达最后nPos位置的时候, 不会再使用f函数中Reduce函数, 而只推到HASH值.(见[5])
  90. 能够推到的那个HASH的那个index就表示为数字的明文.
  91. 注意当然也可能有匹配值有多个的情况, 因为Reduce函数的收敛性的问题,
  92. 原始的HASH和reduce函数的解空间只有缩减的份, 因为Reduce函数只取HASH开头的8bytes作运算.
  93. 所以就需要在一个匹配域中进行查找, 如果CheckAlarm函数验证不通过的, 则说明这个nPos不是所要的位置.
  94. 这样的一种情况就被称为False Alarm.

  95. 如果第一次匹配不成功, 则认为这个HASH是前一个index经过HASH函数推出来的.
  96. Rn-2, 得到一个新的index, 然后一步一步的推到最后, 即Chain链的结束(当然这里只有一次f n-1)
  97. 和上面比较过程相同, 相同的话就可以确定猜测的位置.不同的话, 继续相同的步骤, 只是将Pos的位置向前移.
  98. 直到Pos为0 为止.

  99. 最后将结果放到HASHSET中(hs), 不管是找到了明文, 还是没有发现.
  100. 将明文的信息存放到hs中的工作是由CheckAlarm完成的.(见[5])

  101. 4. 遗留问题

  102. 参数的设定和优化还是有很多不理解的地方. 有一篇关于此的论文无法找到.
  103. chainlen的确定, 还有一些不理解.
  104. 仅大致知道受M = m × l × m0 和 T = t × l × t0 限制(即根据内存大小, 得出最佳计算时间以及成功率)
  105. 还需要仔细仔细地研究一下, 未完待续...


  106. ==============
  107. Appendix
  108. ==============

  109. 函数注释:

  110. [1]
  111. void CChainWalkContext::IndexToPlain()
  112. {
  113. int i;
  114. for (i = m_nPlainLenMax - 1; i >= m_nPlainLenMin - 1; i--)
  115. {
  116. if (m_nIndex >= m_nPlainSpaceUpToX[i])
  117. {
  118. m_nPlainLen = i + 1;
  119. break;
  120. }
  121. }
  122. // 根据 m_nIndex的大小来判断m_nPlainLen的大小
  123. // m_nIndex 就是开始随机生成的, 和之后中间步骤
  124. // m_nPlainSpaceUpToX 用来计算Pxx的
  125. // 当i 时 P 应该有的大小.
  126. // P的概率统计的东东.

  127. uint64 nIndexOfX = m_nIndex - m_nPlainSpaceUpToX[m_nPlainLen - 1]

  128. //此段密码长度应该有的偏移大小.

  129. /*
  130. // Slow version
  131. for (i = m_nPlainLen - 1; i >= 0; i--)
  132. {
  133. m_Plain[i] = m_PlainCharset[nIndexOfX % m_nPlainCharsetLen];
  134. nIndexOfX /= m_nPlainCharsetLen;
  135. }
  136. */

  137. // 事实上完全可以用上面的那个慢速版本来完成
  138. // 为了避免64位的除法运行
  139. // 当数据还是32位时, 就截成32位来算

  140. // Fast version
  141. for (i = m_nPlainLen - 1; i >= 0; i--)
  142. {
  143. #ifdef _WIN32
  144. if (nIndexOfX < 0x100000000I64)
  145. break;
  146. #else
  147. if (nIndexOfX < 0x100000000llu)
  148. break;
  149. #endif
  150. // m_Plain 的方式和16 进制差不多, 不过是明文字符长度进制
  151. // 最先算出来的是最后一位.
  152. m_Plain[i] = m_PlainCharset[nIndexOfX % m_nPlainCharsetLen]; //根据明文字符的内容, 来取关于的大小
  153. nIndexOfX /= m_nPlainCharsetLen;
  154. }

  155. // 算完了 64位, 为什么还要计算32位呢?(见上)
  156. unsigned int nIndexOfX32 = (unsigned int)nIndexOfX;
  157. for (; i >= 0; i--)
  158. {
  159. //m_Plain[i] = m_PlainCharset[nIndexOfX32 % m_nPlainCharsetLen];
  160. //nIndexOfX32 /= m_nPlainCharsetLen;

  161. unsigned int nPlainCharsetLen = m_nPlainCharsetLen;
  162. unsigned int nTemp;
  163. #ifdef _WIN32
  164. __asm
  165. {
  166. mov eax, nIndexOfX32
  167. xor edx, edx
  168. div nPlainCharsetLen
  169. mov nIndexOfX32, eax
  170. mov nTemp, edx
  171. }
  172. #else
  173. __asm__ __volatile__ ( "mov %2, %%eax;"
  174. "xor %%edx, %%edx;"
  175. "divl %3;"
  176. "mov %%eax, %0;"
  177. "mov %%edx, %1;"
  178. : "=m"(nIndexOfX32), "=m"(nTemp)
  179. : "m"(nIndexOfX32), "m"(nPlainCharsetLen)
  180. : "%eax", "%edx"
  181. );
  182. #endif
  183. m_Plain[i] = m_PlainCharset[nTemp];
  184. }
  185. }

  186. [2]

  187. void CChainWalkContext::HashToIndex(int nPos)
  188. {
  189. m_nIndex = (*(uint64*)m_Hash + m_nReduceOffset + nPos) % m_nPlainSpaceTotal;
  190. // nPos 的目的就是要有所变化,每次有加1
  191. // 这就是每个Reduce 函数不同的原因了
  192. // m_nReduceOffset与RaombowTableIndex 相关 见[3]
  193. // m_nReduceOffset = 65536 * nRainbowTableIndex;
  194. // m_Hash是取HASH值的前8 个字节, 因为HASH可能会超过8 bytes
  195. }

  196. [3]

  197. rtgen lm alpha 1 7 3 2100 8000000 all

  198. bool CChainWalkContext::SetRainbowTableIndex(int nRainbowTableIndex) <--------- argv[5] 即 3
  199. {
  200. if (nRainbowTableIndex < 0)
  201. return false;
  202. m_nRainbowTableIndex = nRainbowTableIndex; // 将所要计算的表分成几张表, 而最后all(argv[8]仅仅是生成表的名字罢了)
  203. // 的重复则是为了增加成功率.
  204. m_nReduceOffset = 65536 * nRainbowTableIndex;

  205. return true;
  206. }

  207. [4]

  208. void CCrackEngine::SearchTableChunk(RainbowChain* pChain, int nRainbowChainLen, int nRainbowChainCount, CHashSet& hs)
  209. {
  210. vector<string> vHash;
  211. hs.GetLeftHashWithLen(vHash, CChainWalkContext::GetHashLen());
  212. printf("searching for %d hash%s...\n", vHash.size(),vHash.size() > 1 ? "es" : "");

  213. int nChainWalkStep = 0;
  214. int nFalseAlarm = 0;
  215. int nChainWalkStepDueToFalseAlarm = 0;

  216. int nHashIndex;
  217. for (nHashIndex = 0; nHashIndex < vHash.size(); nHashIndex++)// 针对每个HASH 进行验证
  218. {
  219. unsigned char TargetHash[MAX_HASH_LEN];
  220. int nHashLen;
  221. ParseHash(vHash[nHashIndex], TargetHash, nHashLen);// string -> binary
  222. if (nHashLen != CChainWalkContext::GetHashLen())
  223. printf("debug: nHashLen mismatch\n");

  224. // Rqeuest ChainWalk
  225. bool fNewlyGenerated;
  226. uint64* pStartPosIndexE = m_cws.RequestWalk(TargetHash, // 一些结构的准备
  227. nHashLen,

  228. CChainWalkContext::GetHashRoutineName(),
  229. CChainWalkContext::GetPlainCharsetName(),

  230. CChainWalkContext::GetPlainLenMin(),
  231. CChainWalkContext::GetPlainLenMax(),

  232. CChainWalkContext::GetRainbowTableIndex(),
  233. nRainbowChainLen,
  234. fNewlyGenerated);
  235. //printf("debug: using %s walk for %s\n", fNewlyGenerated ? "newly generated" : "existing",
  236. // vHash[nHashIndex].c_str());

  237. // Walk
  238. int nPos;
  239. for (nPos = nRainbowChainLen - 2; nPos >= 0; nPos--)
  240. {
  241. [4-1] if (fNewlyGenerated) // 是否是新建的. RequestWalk中返回相应的信息
  242. {
  243. CChainWalkContext cwc;
  244. cwc.SetHash(TargetHash);
  245. cwc.HashToIndex(nPos); // 这个就是R n-1 , 第二次 R n-2
  246. int i;
  247. for (i = nPos + 1; i <= nRainbowChainLen - 2; i++)
  248. {
  249. cwc.IndexToPlain(); // 三步为
  250. cwc.PlainToHash(); // f n-1.
  251. cwc.HashToIndex(i); //
  252. }

  253. pStartPosIndexE[nPos] = cwc.GetIndex(); // 得到的值将和pChain[i].nIndexE的所有项进行比较
  254. nChainWalkStep += nRainbowChainLen - 2 - nPos; // 第几步了
  255. }
  256. uint64 nIndexEOfCurPos = pStartPosIndexE[nPos];

  257. // Search matching nIndexE
  258. int nMatchingIndexE = BinarySearch(pChain, nRainbowChainCount, nIndexEOfCurPos); // 二分查找
  259. if (nMatchingIndexE != -1) //找到了
  260. {
  261. int nMatchingIndexEFrom, nMatchingIndexETo;
  262. GetChainIndexRangeWithSameEndpoint(pChain, nRainbowChainCount,
  263. nMatchingIndexE,
  264. nMatchingIndexEFrom,

  265. nMatchingIndexETo);

  266. // 找到相同的区域, 因为完全有可能相同.
  267. // 因为函数的收敛性的问题, 原始的HASH和reduce函数的解空间只有缩减的份
  268. int i;
  269. for (i = nMatchingIndexEFrom; i <= nMatchingIndexETo; i++)
  270. {
  271. // 原来相关的明文存放的是在CheckAlarm 函数中操作的
  272. // 找到一个确实的, 就放入然后退出, 该HASH 的encryptanalysis
  273. if (CheckAlarm(pChain + i, nPos, TargetHash, hs)) // 再进行判断一次. 再正向过程一次.
  274. {
  275. //printf("debug: discarding walk for %s\n", vHash[nHashIndex].c_str());
  276. m_cws.DiscardWalk(pStartPosIndexE);
  277. goto NEXT_HASH;
  278. }
  279. else // 如果不是则说明是一次误报, false alarm.
  280. {
  281. nChainWalkStepDueToFalseAlarm += nPos + 1;
  282. nFalseAlarm++;
  283. }
  284. }
  285. }
  286. }
  287. NEXT_HASH:;
  288. }

  289. //printf("debug: chain walk step: %d\n", nChainWalkStep);
  290. //printf("debug: false alarm: %d\n", nFalseAlarm);
  291. //printf("debug: chain walk step due to false alarm: %d\n", nChainWalkStepDueToFalseAlarm);

  292. m_nTotalChainWalkStep += nChainWalkStep;
  293. m_nTotalFalseAlarm += nFalseAlarm;
  294. m_nTotalChainWalkStepDueToFalseAlarm += nChainWalkStepDueToFalseAlarm;
  295. }

  296. [5]
  297. bool CCrackEngine::CheckAlarm(RainbowChain* pChain, int nGuessedPos, unsigned char* pHash, CHashSet& hs)
  298. {
  299. CChainWalkContext cwc;
  300. cwc.SetIndex(pChain->nIndexS);
  301. int nPos;
  302. for (nPos = 0; nPos < nGuessedPos; nPos++) //根据猜测的位置从头nIndexS推到相应的位置
  303. {
  304. cwc.IndexToPlain();
  305. cwc.PlainToHash();
  306. cwc.HashToIndex(nPos);
  307. }
  308. cwc.IndexToPlain(); +-
  309. cwc.PlainToHash(); \ 只作了一个HASH, 并没有什么Reduce函数(cwc.HashToIndex(nPos) ), 就是为了验证

  310. if (cwc.CheckHash(pHash)) // 验证函数, 比较pHash和生成的函数
  311. {
  312. printf("plaintext of %s is %s\n", cwc.GetHash().c_str(), cwc.GetPlain().c_str());
  313. hs.SetPlain(cwc.GetHash(), cwc.GetPlain(), cwc.GetBinary()); // 结果的放入
  314. return true;
  315. }

  316. return false;

  317. [6]
  318. RequestWalk的目的是为某个需要破解的HASH, 生成一个存放用于匹配pChain[i].nIndexE的数组.
  319. uint64* CChainWalkSet::RequestWalk(unsigned char* pHash, int nHashLen,
  320. string sHashRoutineName,
  321. string sPlainCharsetName, int nPlainLenMin,
  322. int nPlainLenMax,
  323. int nRainbowTableIndex,
  324. int nRainbowChainLen,
  325. bool& fNewlyGenerated)
  326. {
  327. if ( m_sHashRoutineName != sHashRoutineName // 如果相应的参数有所变化, 则所有的东东全部重新设置.
  328. || m_sPlainCharsetName != sPlainCharsetName
  329. || m_nPlainLenMin != nPlainLenMin
  330. || m_nPlainLenMax != nPlainLenMax
  331. || m_nRainbowTableIndex != nRainbowTableIndex
  332. || m_nRainbowChainLen != nRainbowChainLen)
  333. {
  334. DiscardAll(); // <----------- Here

  335. m_sHashRoutineName = sHashRoutineName;
  336. m_sPlainCharsetName = sPlainCharsetName;
  337. m_nPlainLenMin = nPlainLenMin;
  338. m_nPlainLenMax = nPlainLenMax;
  339. m_nRainbowTableIndex = nRainbowTableIndex;
  340. m_nRainbowChainLen = nRainbowChainLen;

  341. ChainWalk cw;
  342. memcpy(cw.Hash, pHash, nHashLen);
  343. cw.pIndexE = new uint64[nRainbowChainLen - 1];
  344. m_lChainWalk.push_back(cw);

  345. fNewlyGenerated = true;
  346. return cw.pIndexE;
  347. }

  348. list<ChainWalk>::iterator it;
  349. for (it = m_lChainWalk.begin(); it != m_lChainWalk.end(); it++)
  350. {
  351. if (memcmp(it->Hash, pHash, nHashLen) == 0) // 判断这个HASH 是否是新,
  352. {
  353. fNewlyGenerated = false;
  354. return it->pIndexE; // 如是, 则返回该 8字节数组的指针
  355. }
  356. }


  357. ChainWalk cw; // ChainWalk 有两个结构 一个放hash值, 另一个放后面8 字节数组的指针
  358. memcpy(cw.Hash, pHash, nHashLen);
  359. cw.pIndexE = new uint64[nRainbowChainLen - 1]; // 一个存放用于匹配pChain[i].mIndexE的数组.
  360. m_lChainWalk.push_back(cw); // 如没有整个HASH, 新建一个, 加入到ChainWalk结构的List

  361. fNewlyGenerated = true;
  362. return cw.pIndexE; //返回的是指向一个放8字节的数组指针
  363. }

复制代码

[ 本帖最后由 Julian_Yuen 于 2008-11-29 21:20 编辑 ]
 楼主| 发表于 2008-11-30 10:15:23 | 显示全部楼层
刚算好几个包,t5600上3小时左右完成一个,结果的上传数据量比较大,一个任务8.58兆。。。
 楼主| 发表于 2008-12-3 10:31:13 | 显示全部楼层
最近boinc的邮件列表中对这个项目讨论挺多(主要是反对的声音。。。),建议大家谨慎参加。


随便引用一段:

1. Do you trust this website? - No
2. Is this website run by a respected university or science institution? - No
3. Do the project administrators clearly identify themselves anywhere on the website with real names and academic accreditations? - No
4. Is this project or website "accountable" to any public body, university, institution or government of a country? - No
5. Can the website administrators be contacted through postal mail at a "Real world" postal address, not a P.O. box number? - No
6. Can the website administrators be contacted by telephone? - No
*************
What is this project trying to achieve? - Crack peoples passwords
Where is this project located? - Some hackers home Garage in Denmark.
Why ??????
Are they selling the results to make a quick buck? - Yes


再来一段:

The only thing about freerainbowtables.com is its doing almost the same
thing as "SHA-1 Collision Search Graz". But the SHA-1 project is run by a
very well respected University in Austria with a very good reputation.

freerainbowtables.com is run by a few hackers trying to make a quick buck
and have fun hacking at the same time.

评分

参与人数 1基本分 +16 维基拼图 +8 收起 理由
霊烏路 空 + 16 + 8

查看全部评分

发表于 2008-12-3 12:35:10 | 显示全部楼层
嗯,的确,人们的怀疑很有道理。不考虑参加此项目
发表于 2011-9-26 23:25:15 | 显示全部楼层
本帖最后由 snowyleaf 于 2011-9-26 23:37 编辑

其实 LS的诸位 的对这个项目的理解都存在 很大的偏差

Hash算法 是不可逆算发
任何对于哈希算法的破解都不能找到加密的原文

这个破解的实质 只是相当于给“山寨货”提供了一个能被当成“原装货”的“包装”或者“名片”。

例如    某人的加密身份信息为AAAA       通过破解发现  伪造信息BBBB 看上去能和 AAAA 一样     
事实上 AAAA 的内容并没被解出  但是其他人却能用BBBB充当AAAA   让别人认为他就是AAAA代表的人

(有点类似于 伪造身份证)


现目前对于 高级哈希算法(以SHA-1为代表)的破解仅仅是在理论阶段(MD5除外)
这个破解项目 只是通过计算找到一个实例  把理论变成实际

事实上即便这一项目成功 也不会产生巨大影响
即便破解算法程序泄漏  被不良人士利用 若想进行破解 仍然需要超级计算机 或者大型 分布式计算集群 进行计算

与这一个项目相似的 还有SHA-1 Collision Search Graz
发表于 2012-2-15 12:27:33 | 显示全部楼层
大叔这个项目已经刹不住车了==
发表于 2012-2-15 16:53:33 | 显示全部楼层
DistrRTgen is finally out of beta and is now in production mode! Let the race to the top begin!

项 ...
Youth 发表于 2008-11-29 20:46



    rainbow table 是彩虹表
发表于 2012-2-15 17:20:33 | 显示全部楼层
回复 7# snowyleaf

彩虹表可不是在寻找Collision,彩虹表是直接建立所有的密文的反向映射,以后直接就可以通过SHA或者MD5字串来查到原文
发表于 2012-2-15 18:24:07 | 显示全部楼层
Rainbow table是universal attack,对任意的hash函数都有效……简单来说,用rainbow table的attack,主要的花费在建立table上,也就是这个项目算的东西;一旦有了这个表,找collision是相当容易的事情……所以这个东西,其实是给别人做刀子,不知道哪天背后就被自己造的刀子捅了……
发表于 2012-2-15 23:43:57 | 显示全部楼层
怪不得看这货有点熟悉,原来是老古董。
反正好话5楼都说尽了,谁还想碰这东西的好自为知。
顺带说一句,在这种人开的网站上注册帐号就已经够危险了。
发表于 2012-2-16 12:21:57 | 显示全部楼层
这个项目也可能促进更高级加密算法或更多加密位数的诞生吧
发表于 2012-4-3 09:35:13 | 显示全部楼层
News

First ever project challenge
I am pleased to announce that we will be hosting our first project challenge!

Rainbow Resurrection: 2012-04-07 16:00:00 GMT - 2012-04-10 16:00:00 GMT

This 72 hour challenge will feature Primegrid style user and team statistics and only work handed out after the start time and returned before the completion time will be counted. In addition all WUs that are part of the challenge will receive 1.25x the credit that is received ordinarily.

The reason for this challenge is two fold:
1) The new hardware has been performing excellently and is averaging less than 20% utilization
2) An ATI/OpenCL app version is in early alpha stages and this challenge will be helpful in seeing if we can handle full 24/7 CPU+GPU where ATI will be added in the future.
31 Mar 2012 | 2:20:24 UTC
发表于 2020-1-8 09:54:32 | 显示全部楼层
项目官网已无法打开,移入关闭项目区
您需要登录后才可以回帖 登录 | 新注册用户

本版积分规则

论坛官方淘宝店开业啦~
欢迎大家多多支持基金会~

小黑屋|手机版|Archiver|中国分布式计算总站 ( 沪ICP备05042587号 )

GMT+8, 2021-7-31 13:32

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表