<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_05_1958251</id>
	<title>Open Source Attempt To Crack GSM Encryption</title>
	<author>timothy</author>
	<datestamp>1260001440000</datestamp>
	<htmltext>Lexta writes with an interesting tidbit from <em>IEEE Spectrum: <i>"'Karsten Nohl, chief research scientist with H4RDW4RE, a Sunnyvale, Calif.-based security research firm, is mounting what could be the most ambitious attempt yet to compromise the GSM phone system.' The intended approach is to create an open source <a href="http://spectrum.ieee.org/telecom/wireless/open-source-effort-to-hack-gsm">project to spread the computation of a giant look-up table</a>  across more than 80 machines. Interestingly, they've openly stated that nVidia's CUDA technology will be used to execute parallel elements of the problem on GPUs as well."</i> </em></htmltext>
<tokenext>Lexta writes with an interesting tidbit from IEEE Spectrum : " 'Karsten Nohl , chief research scientist with H4RDW4RE , a Sunnyvale , Calif.-based security research firm , is mounting what could be the most ambitious attempt yet to compromise the GSM phone system .
' The intended approach is to create an open source project to spread the computation of a giant look-up table across more than 80 machines .
Interestingly , they 've openly stated that nVidia 's CUDA technology will be used to execute parallel elements of the problem on GPUs as well .
"</tokentext>
<sentencetext>Lexta writes with an interesting tidbit from IEEE Spectrum: "'Karsten Nohl, chief research scientist with H4RDW4RE, a Sunnyvale, Calif.-based security research firm, is mounting what could be the most ambitious attempt yet to compromise the GSM phone system.
' The intended approach is to create an open source project to spread the computation of a giant look-up table  across more than 80 machines.
Interestingly, they've openly stated that nVidia's CUDA technology will be used to execute parallel elements of the problem on GPUs as well.
" </sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338312</id>
	<title>Re:A big book</title>
	<author>Anonymous</author>
	<datestamp>1260008040000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>TFA:</p><blockquote><div><p>The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.</p></div></blockquote><p>Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible? That's a ~50,000:1 compression ratio.</p></div><p>Trading space for time.</p><p>128 petabytes would enable instant lookup of collisions.  Cutting size in half, and you'd need 2 operations to find a collision.  Cut size in half again would need to double the time again.  Repeat until you reach the desired space/time trade-off.</p><p>P.C. van Oorschot, M.J. Wiener. Improving meet-in-the-middle attacks by orders of magnitude, Crypto'96, Springer LNCS vol.1109, pp.229-236, 1996. ps, pdf. A more complete treatment is given in the 1999 Journal of Cryptology paper.</p><p>P.C. van Oorschot, M.J. Wiener. Parallel collision search with applications to hash functions and discrete logarithms. pp.210-218, proceedings, 2nd ACM Conference on Computer and Communications Security, Nov. 1994, Fairfax, Virginia. ps, pdf. The Crypto'96 paper builds on this, and a more complete treatment is in the 1999 Journal of Cryptology paper.</p><p>P.C. van Oorschot, M.J. Wiener. Parallel collision search with cryptanalytic applications. Journal of Cryptology, vol.12 no.1 (Jan. 1999) pp.1-28. pdf.</p></div>
	</htmltext>
<tokenext>TFA : The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data , and a computing time of around three months , with the help of about 80 computers.Any crypto experts want to take a stab at explaining , in lay geek terms , how this is even remotely possible ?
That 's a ~ 50,000 : 1 compression ratio.Trading space for time.128 petabytes would enable instant lookup of collisions .
Cutting size in half , and you 'd need 2 operations to find a collision .
Cut size in half again would need to double the time again .
Repeat until you reach the desired space/time trade-off.P.C .
van Oorschot , M.J. Wiener. Improving meet-in-the-middle attacks by orders of magnitude , Crypto'96 , Springer LNCS vol.1109 , pp.229-236 , 1996. ps , pdf .
A more complete treatment is given in the 1999 Journal of Cryptology paper.P.C .
van Oorschot , M.J. Wiener. Parallel collision search with applications to hash functions and discrete logarithms .
pp.210-218 , proceedings , 2nd ACM Conference on Computer and Communications Security , Nov. 1994 , Fairfax , Virginia .
ps , pdf .
The Crypto'96 paper builds on this , and a more complete treatment is in the 1999 Journal of Cryptology paper.P.C .
van Oorschot , M.J. Wiener. Parallel collision search with cryptanalytic applications .
Journal of Cryptology , vol.12 no.1 ( Jan. 1999 ) pp.1-28 .
pdf .</tokentext>
<sentencetext>TFA:The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible?
That's a ~50,000:1 compression ratio.Trading space for time.128 petabytes would enable instant lookup of collisions.
Cutting size in half, and you'd need 2 operations to find a collision.
Cut size in half again would need to double the time again.
Repeat until you reach the desired space/time trade-off.P.C.
van Oorschot, M.J. Wiener. Improving meet-in-the-middle attacks by orders of magnitude, Crypto'96, Springer LNCS vol.1109, pp.229-236, 1996. ps, pdf.
A more complete treatment is given in the 1999 Journal of Cryptology paper.P.C.
van Oorschot, M.J. Wiener. Parallel collision search with applications to hash functions and discrete logarithms.
pp.210-218, proceedings, 2nd ACM Conference on Computer and Communications Security, Nov. 1994, Fairfax, Virginia.
ps, pdf.
The Crypto'96 paper builds on this, and a more complete treatment is in the 1999 Journal of Cryptology paper.P.C.
van Oorschot, M.J. Wiener. Parallel collision search with cryptanalytic applications.
Journal of Cryptology, vol.12 no.1 (Jan. 1999) pp.1-28.
pdf.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337922</id>
	<title>Wheew</title>
	<author>DaHat</author>
	<datestamp>1260005160000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p>Makes me glad I use CDMA<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>Makes me glad I use CDMA ; )</tokentext>
<sentencetext>Makes me glad I use CDMA ;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30350002</id>
	<title>Re:A big book</title>
	<author>Anonymous</author>
	<datestamp>1260129540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Finally... a comment worth the modtag 'informative'.  I recently learned (and understood) the time/space tradeoff, but it plus journal references is frickin' awesome.</p><p>For anyone that doesn't get what AC and Oorschot/Wiener are talking about, one keeps tabs on whole families of computational answers. If the encryption takes 50 iterations through the algorithm, build a lookup table for what the intermediate value is on the 30th cycle then do all permutations of the last 20 cycles based on this knowledge.  You don't get the answer instantly, but it doesn't take 50k years, either.</p><p>This, incidentally, is why there are whole fleets of Rainbow Tables.  Different ones for different goals and optimizations.</p><p>Posted A/C because I'm obviously not expert on the concept and sure to get mocked/corrected, but at the same time not seeing much lay language in the parent post.</p></htmltext>
<tokenext>Finally... a comment worth the modtag 'informative' .
I recently learned ( and understood ) the time/space tradeoff , but it plus journal references is frickin ' awesome.For anyone that does n't get what AC and Oorschot/Wiener are talking about , one keeps tabs on whole families of computational answers .
If the encryption takes 50 iterations through the algorithm , build a lookup table for what the intermediate value is on the 30th cycle then do all permutations of the last 20 cycles based on this knowledge .
You do n't get the answer instantly , but it does n't take 50k years , either.This , incidentally , is why there are whole fleets of Rainbow Tables .
Different ones for different goals and optimizations.Posted A/C because I 'm obviously not expert on the concept and sure to get mocked/corrected , but at the same time not seeing much lay language in the parent post .</tokentext>
<sentencetext>Finally... a comment worth the modtag 'informative'.
I recently learned (and understood) the time/space tradeoff, but it plus journal references is frickin' awesome.For anyone that doesn't get what AC and Oorschot/Wiener are talking about, one keeps tabs on whole families of computational answers.
If the encryption takes 50 iterations through the algorithm, build a lookup table for what the intermediate value is on the 30th cycle then do all permutations of the last 20 cycles based on this knowledge.
You don't get the answer instantly, but it doesn't take 50k years, either.This, incidentally, is why there are whole fleets of Rainbow Tables.
Different ones for different goals and optimizations.Posted A/C because I'm obviously not expert on the concept and sure to get mocked/corrected, but at the same time not seeing much lay language in the parent post.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338312</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338298</id>
	<title>Incorrect time estimate? BOINC?</title>
	<author>tagno25</author>
	<datestamp>1260007860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>TFA:</p><blockquote><div><p>The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.</p></div></blockquote><p>Wouldn't they need about 100,000 computers for it to take one year?  And why don't they just use BOINC and enlist random computers and attempt to get more computing power?</p></div>
	</htmltext>
<tokenext>TFA : The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data , and a computing time of around three months , with the help of about 80 computers.Would n't they need about 100,000 computers for it to take one year ?
And why do n't they just use BOINC and enlist random computers and attempt to get more computing power ?</tokentext>
<sentencetext>TFA:The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.Wouldn't they need about 100,000 computers for it to take one year?
And why don't they just use BOINC and enlist random computers and attempt to get more computing power?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30340086</id>
	<title>Apparently my IE8 is an old browser?!</title>
	<author>Anonymous</author>
	<datestamp>1260022560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>-1 vote to forced user agent by websites</p></htmltext>
<tokenext>-1 vote to forced user agent by websites</tokentext>
<sentencetext>-1 vote to forced user agent by websites</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338236</id>
	<title>Two points..</title>
	<author>Anonymous</author>
	<datestamp>1260007320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>1) Only applies to 2G/GSM, not 3G/UMTS<br>
2) This has been known pretty much from the beginning, and updating has been started years ago. As said in TFA, only news of this is the plan to make it publicly available.</htmltext>
<tokenext>1 ) Only applies to 2G/GSM , not 3G/UMTS 2 ) This has been known pretty much from the beginning , and updating has been started years ago .
As said in TFA , only news of this is the plan to make it publicly available .</tokentext>
<sentencetext>1) Only applies to 2G/GSM, not 3G/UMTS
2) This has been known pretty much from the beginning, and updating has been started years ago.
As said in TFA, only news of this is the plan to make it publicly available.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338432</id>
	<title>Hmm... just when Google want us to leave GSM too!</title>
	<author>Anonymous</author>
	<datestamp>1260008940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It must be purely a co-incidence that Google Voice is rumoured to be coming on the Android Googlephone real soon now.<nobr> <wbr></nobr>;-)</p></htmltext>
<tokenext>It must be purely a co-incidence that Google Voice is rumoured to be coming on the Android Googlephone real soon now .
; - )</tokentext>
<sentencetext>It must be purely a co-incidence that Google Voice is rumoured to be coming on the Android Googlephone real soon now.
;-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339234</id>
	<title>why?</title>
	<author>Anonymous</author>
	<datestamp>1260015180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>just curious as to why 'we' need an open source crack for GSM?</p></htmltext>
<tokenext>just curious as to why 'we ' need an open source crack for GSM ?</tokentext>
<sentencetext>just curious as to why 'we' need an open source crack for GSM?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30347704</id>
	<title>Re:Big deal</title>
	<author>Anonymous</author>
	<datestamp>1260107220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>No one uses their phone to make secure calls.</p></htmltext>
<tokenext>No one uses their phone to make secure calls .</tokentext>
<sentencetext>No one uses their phone to make secure calls.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338296</id>
	<title>Re:A big book</title>
	<author>0123456</author>
	<datestamp>1260007800000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible? That's a ~50,000:1 compression ratio.</p></div><p>I think what they're saying is that instead of building a table which will allow you to simply look up the relevant key from some known encrypted data, they'd build a smaller table which would allow you to substantially reduce decryption time.</p></div>
	</htmltext>
<tokenext>Any crypto experts want to take a stab at explaining , in lay geek terms , how this is even remotely possible ?
That 's a ~ 50,000 : 1 compression ratio.I think what they 're saying is that instead of building a table which will allow you to simply look up the relevant key from some known encrypted data , they 'd build a smaller table which would allow you to substantially reduce decryption time .</tokentext>
<sentencetext>Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible?
That's a ~50,000:1 compression ratio.I think what they're saying is that instead of building a table which will allow you to simply look up the relevant key from some known encrypted data, they'd build a smaller table which would allow you to substantially reduce decryption time.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339894</id>
	<title>Re:Big deal</title>
	<author>skine</author>
	<datestamp>1260020700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I still use a Zach Morris phone, you insensitive clod!</p><p>The only way I can receive texts is through Morris code.</p></htmltext>
<tokenext>I still use a Zach Morris phone , you insensitive clod ! The only way I can receive texts is through Morris code .</tokentext>
<sentencetext>I still use a Zach Morris phone, you insensitive clod!The only way I can receive texts is through Morris code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174</id>
	<title>A big book</title>
	<author>StreetStealth</author>
	<datestamp>1260006900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>TFA:</p><blockquote><div><p>The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.</p></div></blockquote><p>Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible? That's a ~50,000:1 compression ratio.</p></div>
	</htmltext>
<tokenext>TFA : The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data , and a computing time of around three months , with the help of about 80 computers.Any crypto experts want to take a stab at explaining , in lay geek terms , how this is even remotely possible ?
That 's a ~ 50,000 : 1 compression ratio .</tokentext>
<sentencetext>TFA:The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible?
That's a ~50,000:1 compression ratio.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339816</id>
	<title>Re:Big deal</title>
	<author>sTeF</author>
	<datestamp>1260020040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>afaik you can DOS the UMTS layer, in which case the phone reverts to GSM encryption.</htmltext>
<tokenext>afaik you can DOS the UMTS layer , in which case the phone reverts to GSM encryption .</tokentext>
<sentencetext>afaik you can DOS the UMTS layer, in which case the phone reverts to GSM encryption.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338128</id>
	<title>Not in California</title>
	<author>Anonymous</author>
	<datestamp>1260006540000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>In other news today, four people were arrested in Sunnyvale for a half dozen felonies. The men, all apparently clueless foreign nationals with gender neutral names said they are innocent and intend to fight their charges to the Supreme Court as soon as their parents wire them the Euros to post bail.</p></htmltext>
<tokenext>In other news today , four people were arrested in Sunnyvale for a half dozen felonies .
The men , all apparently clueless foreign nationals with gender neutral names said they are innocent and intend to fight their charges to the Supreme Court as soon as their parents wire them the Euros to post bail .</tokentext>
<sentencetext>In other news today, four people were arrested in Sunnyvale for a half dozen felonies.
The men, all apparently clueless foreign nationals with gender neutral names said they are innocent and intend to fight their charges to the Supreme Court as soon as their parents wire them the Euros to post bail.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338700</id>
	<title>compromise the GSM phone system</title>
	<author>Stan92057</author>
	<datestamp>1260011160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>"what could be the most ambitious attempt yet to compromise the GSM phone system"
Open Source doesn't need bad press if you are trying to get everyone to switch to it, They "Anyone using a business computer/home computer" would feel safe how? If proving it cant be trusted, then by all means yes go ahead with the project.</htmltext>
<tokenext>" what could be the most ambitious attempt yet to compromise the GSM phone system " Open Source does n't need bad press if you are trying to get everyone to switch to it , They " Anyone using a business computer/home computer " would feel safe how ?
If proving it cant be trusted , then by all means yes go ahead with the project .</tokentext>
<sentencetext>"what could be the most ambitious attempt yet to compromise the GSM phone system"
Open Source doesn't need bad press if you are trying to get everyone to switch to it, They "Anyone using a business computer/home computer" would feel safe how?
If proving it cant be trusted, then by all means yes go ahead with the project.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30342744</id>
	<title>Pointless to do it like this</title>
	<author>Anonymous</author>
	<datestamp>1260109320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sounds to me like they're not really embracing the Kerckhoff principle with this attack.</p><p>Why not try to reproduce what Barkan, Biham, Keller did and do that instead - assuming the targets use A5/2.</p><p>"In 2006 Elad Barkan, Eli Biham and Nathan Keller demonstrated attacks against A5/1, A5/3, or even GPRS that allow attackers to tap GSM mobile phone conversations and decrypt them either in real-time, or at any later time."</p></htmltext>
<tokenext>Sounds to me like they 're not really embracing the Kerckhoff principle with this attack.Why not try to reproduce what Barkan , Biham , Keller did and do that instead - assuming the targets use A5/2 .
" In 2006 Elad Barkan , Eli Biham and Nathan Keller demonstrated attacks against A5/1 , A5/3 , or even GPRS that allow attackers to tap GSM mobile phone conversations and decrypt them either in real-time , or at any later time .
"</tokentext>
<sentencetext>Sounds to me like they're not really embracing the Kerckhoff principle with this attack.Why not try to reproduce what Barkan, Biham, Keller did and do that instead - assuming the targets use A5/2.
"In 2006 Elad Barkan, Eli Biham and Nathan Keller demonstrated attacks against A5/1, A5/3, or even GPRS that allow attackers to tap GSM mobile phone conversations and decrypt them either in real-time, or at any later time.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338312</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30342906</id>
	<title>Re:Sp3ll1ng</title>
	<author>Anonymous</author>
	<datestamp>1260111600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>l0pht was pretty serious and successful.</p></htmltext>
<tokenext>l0pht was pretty serious and successful .</tokentext>
<sentencetext>l0pht was pretty serious and successful.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341088</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339124</id>
	<title>donate</title>
	<author>shata</author>
	<datestamp>1260014400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Link to the project web-site:<br>
<a href="http://wiki.thc.org/gsm" title="thc.org" rel="nofollow">http://wiki.thc.org/gsm</a> [thc.org] <br>
<br>
If you're IT admin of school with 5000 idle computers, consider donating some GPU time<nobr> <wbr></nobr>:-)</htmltext>
<tokenext>Link to the project web-site : http : //wiki.thc.org/gsm [ thc.org ] If you 're IT admin of school with 5000 idle computers , consider donating some GPU time : - )</tokentext>
<sentencetext>Link to the project web-site:
http://wiki.thc.org/gsm [thc.org] 

If you're IT admin of school with 5000 idle computers, consider donating some GPU time :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30347394</id>
	<title>comments from TFA</title>
	<author>Eil</author>
	<datestamp>1260105120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>The encryption technology used to prevent eavesdropping in GSM (Global System for Mobile communications), the world's most widely used cellphone system, has more security holes than Swiss cheese, according to an expert who plans to poke a big hole of his own.</p></div></blockquote><p>I hope I am not the first to say: "giggity."</p><blockquote><div><p>Each GSM phone has its own secret key, which is known by the network. Every time a call is initiated, a new session key for that particular call is derived from the secret key and used to encrypt the call. Nohl aims to crack the session key.</p></div></blockquote><p>This actually doesn't sound like a bad encryption scheme.</p><blockquote><div><p>To speed up computing time, the project relies on some components not always found in your standard PC, such as Nvidia Corp.'s CUDA (Compute Unified Device Architecture) graphics cards and Xilinx Virtex field-programmable gate arrays (FPGAs).</p></div></blockquote><p>So, are those of us without fancy video cards or FPGAs allowed to help? Even if we can't compute keys as quickly?</p><blockquote><div><p>That's the point Nohl hopes to drive home: The A5/1 algorithm is a broken 64-bit encryption technology, a relic of the Cold War era, when laws prohibited the export of strong encryption technology from the United States. It needs to be replaced--ideally by the much stronger, 128-bit A5/3 system</p></div></blockquote><p>So GSM itself isn't that insecure, it's that they're using a short key length. This is rather old news then. All they are doing is brute-forcing the whole key space rather than breaking the algorithm. This is basically what brought down <a href="http://distributed.net/rc5/" title="distributed.net">RC5-56</a> [distributed.net] and <a href="http://w2.eff.org/Privacy/Crypto/Crypto\_misc/DESCracker/HTML/19980716\_eff\_des\_faq.html" title="eff.org">DES</a> [eff.org] (although DES had other flaws as well).</p></div>
	</htmltext>
<tokenext>The encryption technology used to prevent eavesdropping in GSM ( Global System for Mobile communications ) , the world 's most widely used cellphone system , has more security holes than Swiss cheese , according to an expert who plans to poke a big hole of his own.I hope I am not the first to say : " giggity .
" Each GSM phone has its own secret key , which is known by the network .
Every time a call is initiated , a new session key for that particular call is derived from the secret key and used to encrypt the call .
Nohl aims to crack the session key.This actually does n't sound like a bad encryption scheme.To speed up computing time , the project relies on some components not always found in your standard PC , such as Nvidia Corp. 's CUDA ( Compute Unified Device Architecture ) graphics cards and Xilinx Virtex field-programmable gate arrays ( FPGAs ) .So , are those of us without fancy video cards or FPGAs allowed to help ?
Even if we ca n't compute keys as quickly ? That 's the point Nohl hopes to drive home : The A5/1 algorithm is a broken 64-bit encryption technology , a relic of the Cold War era , when laws prohibited the export of strong encryption technology from the United States .
It needs to be replaced--ideally by the much stronger , 128-bit A5/3 systemSo GSM itself is n't that insecure , it 's that they 're using a short key length .
This is rather old news then .
All they are doing is brute-forcing the whole key space rather than breaking the algorithm .
This is basically what brought down RC5-56 [ distributed.net ] and DES [ eff.org ] ( although DES had other flaws as well ) .</tokentext>
<sentencetext>The encryption technology used to prevent eavesdropping in GSM (Global System for Mobile communications), the world's most widely used cellphone system, has more security holes than Swiss cheese, according to an expert who plans to poke a big hole of his own.I hope I am not the first to say: "giggity.
"Each GSM phone has its own secret key, which is known by the network.
Every time a call is initiated, a new session key for that particular call is derived from the secret key and used to encrypt the call.
Nohl aims to crack the session key.This actually doesn't sound like a bad encryption scheme.To speed up computing time, the project relies on some components not always found in your standard PC, such as Nvidia Corp.'s CUDA (Compute Unified Device Architecture) graphics cards and Xilinx Virtex field-programmable gate arrays (FPGAs).So, are those of us without fancy video cards or FPGAs allowed to help?
Even if we can't compute keys as quickly?That's the point Nohl hopes to drive home: The A5/1 algorithm is a broken 64-bit encryption technology, a relic of the Cold War era, when laws prohibited the export of strong encryption technology from the United States.
It needs to be replaced--ideally by the much stronger, 128-bit A5/3 systemSo GSM itself isn't that insecure, it's that they're using a short key length.
This is rather old news then.
All they are doing is brute-forcing the whole key space rather than breaking the algorithm.
This is basically what brought down RC5-56 [distributed.net] and DES [eff.org] (although DES had other flaws as well).
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30340696</id>
	<title>Re:Hackers Sell Out</title>
	<author>FatdogHaiku</author>
	<datestamp>1260028920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Wow, even hacking is branded these days.</p><p>I look forward to the Pepsi Challenge being revised to an RSA cracking contest.</p></div><p>I prefer algorithm "B"<br>Mmmm, algorithm... {drool sound}</p></div>
	</htmltext>
<tokenext>Wow , even hacking is branded these days.I look forward to the Pepsi Challenge being revised to an RSA cracking contest.I prefer algorithm " B " Mmmm , algorithm... { drool sound }</tokentext>
<sentencetext>Wow, even hacking is branded these days.I look forward to the Pepsi Challenge being revised to an RSA cracking contest.I prefer algorithm "B"Mmmm, algorithm... {drool sound}
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000</id>
	<title>Big deal</title>
	<author>Rob Kaper</author>
	<datestamp>1260005640000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p>Big deal. No one still uses their cellphone to make calls anyway.</p></htmltext>
<tokenext>Big deal .
No one still uses their cellphone to make calls anyway .</tokentext>
<sentencetext>Big deal.
No one still uses their cellphone to make calls anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338354</id>
	<title>Re:A big book</title>
	<author>Anonymous</author>
	<datestamp>1260008400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>TFA:</p><blockquote><div><p>The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.</p></div></blockquote><p>Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible? That's a ~50,000:1 compression ratio.</p></div><p>IIRC it was found some years ago that while GSM security in principle was OK, most of the bits of the encryption key are always set to zero.</p><p>I don't think this is true of 3G GSM though...</p></div>
	</htmltext>
<tokenext>TFA : The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data , and a computing time of around three months , with the help of about 80 computers.Any crypto experts want to take a stab at explaining , in lay geek terms , how this is even remotely possible ?
That 's a ~ 50,000 : 1 compression ratio.IIRC it was found some years ago that while GSM security in principle was OK , most of the bits of the encryption key are always set to zero.I do n't think this is true of 3G GSM though.. .</tokentext>
<sentencetext>TFA:The A5/1 cracking project aims to compress the 128-petabyte A5/1 codebook -- which would require more than 100 000 years of computing by a single PC to crack--to around 2 or 3 terabytes of data, and a computing time of around three months, with the help of about 80 computers.Any crypto experts want to take a stab at explaining, in lay geek terms, how this is even remotely possible?
That's a ~50,000:1 compression ratio.IIRC it was found some years ago that while GSM security in principle was OK, most of the bits of the encryption key are always set to zero.I don't think this is true of 3G GSM though...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338014</id>
	<title>Oh my gosh</title>
	<author>exsequor</author>
	<datestamp>1260005760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>I sure hope they aren't able to listen to my phone sex...</htmltext>
<tokenext>I sure hope they are n't able to listen to my phone sex.. .</tokentext>
<sentencetext>I sure hope they aren't able to listen to my phone sex...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341088</id>
	<title>Sp3ll1ng</title>
	<author>dangitman</author>
	<datestamp>1260034380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>H4RDW4RE?</p><p>Are we really supposed to take a company seriously, when its own name substitutes numerals for letters?</p></htmltext>
<tokenext>H4RDW4RE ? Are we really supposed to take a company seriously , when its own name substitutes numerals for letters ?</tokentext>
<sentencetext>H4RDW4RE?Are we really supposed to take a company seriously, when its own name substitutes numerals for letters?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338602</id>
	<title>Re:A big book</title>
	<author>kasperd</author>
	<datestamp>1260010200000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>Any crypto experts want to take a stab at explaining</p></div></blockquote><p>The article doesn't contain enough information about A5/1 or the details of the attack for a crypto expert to explain exactly what he plan to do. However it does mention that he intend to create a rainbow table, so I can at least explain what a rainbow table is, and what the 128PB might mean. The article say it is a 64 bit encryption, but 128PB doesn't sound like the right size given a 64 bit encryption, the 128PB sounds more like a 54 bit encryption. And though it doesn't sound like a huge difference those 10 bits does mean a factor of 1024 times less work to brute force, and these days the difference between 54 and 64 bits may very well be the difference between feasible and not feasible to break. Of course in a few years 64 bits may be feasible to brute force as well.<br> <br>

Compressing 128PB down to 2-3TB doesn't sound realistic at first, but then consider that those 128PB are not just 128PB of random data, they are generated by a very simple algorithm. The entire code to generate those 128PB would probably fit in less than 1MB. But the time it would take to actually run the code for long enough to generate the 128PB is prohibitive. Also notice, that what is going to happen is not really a compression of the 128PB of data. The output of the algorithm is going to be a few TB of data, but that data can't actually be used to reproduce the original 128PB of data, which wouldn't be very interesting anyway. What you really want is a function that given some input can output the encryption key, and that can happen through a very simple table lookup, which would be very fast, but infeasible since very few people have the resources to store the complete 128PB lookup table. Instead you use a more complicated algorithm, which use 50.000 times less stored data, but OTOH may run 100.000 times (or even more) slower than the simple table lookup. But 100.000 table lookups would still only take a fraction of a second on a modern CPU.<br> <br>

Back to the rainbow tables. It is a tool to speed up the task of reversing a one way function. A one way function is a function that maps from one set of values to another set of values. The function is fast to compute in one direction, but there is no simple way to compute in the other direction. One example of a one way function is a hash function, which maps from strings of arbitrary lengths to the much smaller set of strings of one fixed length.<br> <br>

Let's assume our one way function is called f and maps from the set S to the set T. Then we can define a different function g, which maps from T to some interesting subset of S. For example it has been used in the past with a function that maps from 128 bit strings (outputs from MD5) to the set of passwords consisting of 7 alphanumeric characters (which is a subset of the possible inputs to MD5). If you combine g and f, you get a function mapping from T to T. If you start with a value in T and keep applying this combination, you will keep getting values in T.<br> <br>

Now you decide how many times in a row you will apply this combination, let's call that number n. A small n will produce very large rainbow tables, that may be faster to use. OTOH a large n will produce smaller rainbow tables that will be slower to use. This choice is the compromise mentioned in the article. He is probably going to use a value of n around 65536 or so.<br> <br>

Now you start producing chains (this is the large amount of work that this project will aim to distribute). You take some input in T, then you apply the combination of the two functions n times and get an output in T. You repeat that with a few hundred billion different values in T. The output will be a lot of pairs of values, from those pairs you create a lookup table.<br> <br>

Now assume you have a value x, which is the output of the one way function f, and you want to find out what the input may have been. Then you can apply the combination of functions n times and get n different values in T, look for all of them in your lookup table, if you find any them, you will get a value that was n steps earlier in the iteration of the functions. You can take that value and then apply the combination to that another n times. Now you have one chain, and if your x is somewhere in the chain, then you will know an input that could have produced x as output.<br> <br>

What I have described here is a little simpler than rainbow tables, it suffers from a problem with collisions, which means you may get a different chain, which would end in the same place, but may not have gone through x. Rainbow tables are a bit more complicated to avoid that problem.<br> <br>

How does this apply to breaking encryption? I don't actually know, but I do have a guess. (The article doesn't state it, it just says he will use rainbow tables). Maybe the beginning of the session contains some predictable information. Then the one way function you are interested in reversing is one that maps from keys to the predictable information in the beginning of the session.</p></div>
	</htmltext>
<tokenext>Any crypto experts want to take a stab at explainingThe article does n't contain enough information about A5/1 or the details of the attack for a crypto expert to explain exactly what he plan to do .
However it does mention that he intend to create a rainbow table , so I can at least explain what a rainbow table is , and what the 128PB might mean .
The article say it is a 64 bit encryption , but 128PB does n't sound like the right size given a 64 bit encryption , the 128PB sounds more like a 54 bit encryption .
And though it does n't sound like a huge difference those 10 bits does mean a factor of 1024 times less work to brute force , and these days the difference between 54 and 64 bits may very well be the difference between feasible and not feasible to break .
Of course in a few years 64 bits may be feasible to brute force as well .
Compressing 128PB down to 2-3TB does n't sound realistic at first , but then consider that those 128PB are not just 128PB of random data , they are generated by a very simple algorithm .
The entire code to generate those 128PB would probably fit in less than 1MB .
But the time it would take to actually run the code for long enough to generate the 128PB is prohibitive .
Also notice , that what is going to happen is not really a compression of the 128PB of data .
The output of the algorithm is going to be a few TB of data , but that data ca n't actually be used to reproduce the original 128PB of data , which would n't be very interesting anyway .
What you really want is a function that given some input can output the encryption key , and that can happen through a very simple table lookup , which would be very fast , but infeasible since very few people have the resources to store the complete 128PB lookup table .
Instead you use a more complicated algorithm , which use 50.000 times less stored data , but OTOH may run 100.000 times ( or even more ) slower than the simple table lookup .
But 100.000 table lookups would still only take a fraction of a second on a modern CPU .
Back to the rainbow tables .
It is a tool to speed up the task of reversing a one way function .
A one way function is a function that maps from one set of values to another set of values .
The function is fast to compute in one direction , but there is no simple way to compute in the other direction .
One example of a one way function is a hash function , which maps from strings of arbitrary lengths to the much smaller set of strings of one fixed length .
Let 's assume our one way function is called f and maps from the set S to the set T. Then we can define a different function g , which maps from T to some interesting subset of S. For example it has been used in the past with a function that maps from 128 bit strings ( outputs from MD5 ) to the set of passwords consisting of 7 alphanumeric characters ( which is a subset of the possible inputs to MD5 ) .
If you combine g and f , you get a function mapping from T to T. If you start with a value in T and keep applying this combination , you will keep getting values in T . Now you decide how many times in a row you will apply this combination , let 's call that number n. A small n will produce very large rainbow tables , that may be faster to use .
OTOH a large n will produce smaller rainbow tables that will be slower to use .
This choice is the compromise mentioned in the article .
He is probably going to use a value of n around 65536 or so .
Now you start producing chains ( this is the large amount of work that this project will aim to distribute ) .
You take some input in T , then you apply the combination of the two functions n times and get an output in T. You repeat that with a few hundred billion different values in T. The output will be a lot of pairs of values , from those pairs you create a lookup table .
Now assume you have a value x , which is the output of the one way function f , and you want to find out what the input may have been .
Then you can apply the combination of functions n times and get n different values in T , look for all of them in your lookup table , if you find any them , you will get a value that was n steps earlier in the iteration of the functions .
You can take that value and then apply the combination to that another n times .
Now you have one chain , and if your x is somewhere in the chain , then you will know an input that could have produced x as output .
What I have described here is a little simpler than rainbow tables , it suffers from a problem with collisions , which means you may get a different chain , which would end in the same place , but may not have gone through x. Rainbow tables are a bit more complicated to avoid that problem .
How does this apply to breaking encryption ?
I do n't actually know , but I do have a guess .
( The article does n't state it , it just says he will use rainbow tables ) .
Maybe the beginning of the session contains some predictable information .
Then the one way function you are interested in reversing is one that maps from keys to the predictable information in the beginning of the session .</tokentext>
<sentencetext>Any crypto experts want to take a stab at explainingThe article doesn't contain enough information about A5/1 or the details of the attack for a crypto expert to explain exactly what he plan to do.
However it does mention that he intend to create a rainbow table, so I can at least explain what a rainbow table is, and what the 128PB might mean.
The article say it is a 64 bit encryption, but 128PB doesn't sound like the right size given a 64 bit encryption, the 128PB sounds more like a 54 bit encryption.
And though it doesn't sound like a huge difference those 10 bits does mean a factor of 1024 times less work to brute force, and these days the difference between 54 and 64 bits may very well be the difference between feasible and not feasible to break.
Of course in a few years 64 bits may be feasible to brute force as well.
Compressing 128PB down to 2-3TB doesn't sound realistic at first, but then consider that those 128PB are not just 128PB of random data, they are generated by a very simple algorithm.
The entire code to generate those 128PB would probably fit in less than 1MB.
But the time it would take to actually run the code for long enough to generate the 128PB is prohibitive.
Also notice, that what is going to happen is not really a compression of the 128PB of data.
The output of the algorithm is going to be a few TB of data, but that data can't actually be used to reproduce the original 128PB of data, which wouldn't be very interesting anyway.
What you really want is a function that given some input can output the encryption key, and that can happen through a very simple table lookup, which would be very fast, but infeasible since very few people have the resources to store the complete 128PB lookup table.
Instead you use a more complicated algorithm, which use 50.000 times less stored data, but OTOH may run 100.000 times (or even more) slower than the simple table lookup.
But 100.000 table lookups would still only take a fraction of a second on a modern CPU.
Back to the rainbow tables.
It is a tool to speed up the task of reversing a one way function.
A one way function is a function that maps from one set of values to another set of values.
The function is fast to compute in one direction, but there is no simple way to compute in the other direction.
One example of a one way function is a hash function, which maps from strings of arbitrary lengths to the much smaller set of strings of one fixed length.
Let's assume our one way function is called f and maps from the set S to the set T. Then we can define a different function g, which maps from T to some interesting subset of S. For example it has been used in the past with a function that maps from 128 bit strings (outputs from MD5) to the set of passwords consisting of 7 alphanumeric characters (which is a subset of the possible inputs to MD5).
If you combine g and f, you get a function mapping from T to T. If you start with a value in T and keep applying this combination, you will keep getting values in T. 

Now you decide how many times in a row you will apply this combination, let's call that number n. A small n will produce very large rainbow tables, that may be faster to use.
OTOH a large n will produce smaller rainbow tables that will be slower to use.
This choice is the compromise mentioned in the article.
He is probably going to use a value of n around 65536 or so.
Now you start producing chains (this is the large amount of work that this project will aim to distribute).
You take some input in T, then you apply the combination of the two functions n times and get an output in T. You repeat that with a few hundred billion different values in T. The output will be a lot of pairs of values, from those pairs you create a lookup table.
Now assume you have a value x, which is the output of the one way function f, and you want to find out what the input may have been.
Then you can apply the combination of functions n times and get n different values in T, look for all of them in your lookup table, if you find any them, you will get a value that was n steps earlier in the iteration of the functions.
You can take that value and then apply the combination to that another n times.
Now you have one chain, and if your x is somewhere in the chain, then you will know an input that could have produced x as output.
What I have described here is a little simpler than rainbow tables, it suffers from a problem with collisions, which means you may get a different chain, which would end in the same place, but may not have gone through x. Rainbow tables are a bit more complicated to avoid that problem.
How does this apply to breaking encryption?
I don't actually know, but I do have a guess.
(The article doesn't state it, it just says he will use rainbow tables).
Maybe the beginning of the session contains some predictable information.
Then the one way function you are interested in reversing is one that maps from keys to the predictable information in the beginning of the session.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30345278</id>
	<title>Re:Incorrect time estimate? BOINC?</title>
	<author>KZigurs</author>
	<datestamp>1260132600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>it isn't 128PB to start with. Actual key length is 2^48 if I remember correctly - there are some rather huge issues with the A5/1.</p></htmltext>
<tokenext>it is n't 128PB to start with .
Actual key length is 2 ^ 48 if I remember correctly - there are some rather huge issues with the A5/1 .</tokentext>
<sentencetext>it isn't 128PB to start with.
Actual key length is 2^48 if I remember correctly - there are some rather huge issues with the A5/1.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338298</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337980</id>
	<title>Hackers Sell Out</title>
	<author>Anonymous</author>
	<datestamp>1260005460000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>Interestingly, they've openly stated that nVidia's CUDA technology will be used to execute parallel elements of the problem on GPUs as well.</i></p><p>Wow, even hacking is branded these days.</p><p>I look forward to the Pepsi Challenge being revised to an RSA cracking contest.</p></htmltext>
<tokenext>Interestingly , they 've openly stated that nVidia 's CUDA technology will be used to execute parallel elements of the problem on GPUs as well.Wow , even hacking is branded these days.I look forward to the Pepsi Challenge being revised to an RSA cracking contest .</tokentext>
<sentencetext>Interestingly, they've openly stated that nVidia's CUDA technology will be used to execute parallel elements of the problem on GPUs as well.Wow, even hacking is branded these days.I look forward to the Pepsi Challenge being revised to an RSA cracking contest.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338366</id>
	<title>Re:A big book</title>
	<author>bhima</author>
	<datestamp>1260008580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>The key phrases you are looking for are "rainbow tables"; "time / memory trade-off"; "distributed computing"; "embarrassingly parallel"; "GPGPU Computing" and probably "More's Law".</p><p>So now computers are faster than when they cooked that "100,000 years" phrase.  They are employing many different computers with multiple cores.  GPUs are much faster at this calculation that X86 processors.  Rainbow tables are ingenious methods to store precomputed results, so the actual cracking is simple comparisons between encrypted text with known values and the data you are attacking.</p></htmltext>
<tokenext>The key phrases you are looking for are " rainbow tables " ; " time / memory trade-off " ; " distributed computing " ; " embarrassingly parallel " ; " GPGPU Computing " and probably " More 's Law " .So now computers are faster than when they cooked that " 100,000 years " phrase .
They are employing many different computers with multiple cores .
GPUs are much faster at this calculation that X86 processors .
Rainbow tables are ingenious methods to store precomputed results , so the actual cracking is simple comparisons between encrypted text with known values and the data you are attacking .</tokentext>
<sentencetext>The key phrases you are looking for are "rainbow tables"; "time / memory trade-off"; "distributed computing"; "embarrassingly parallel"; "GPGPU Computing" and probably "More's Law".So now computers are faster than when they cooked that "100,000 years" phrase.
They are employing many different computers with multiple cores.
GPUs are much faster at this calculation that X86 processors.
Rainbow tables are ingenious methods to store precomputed results, so the actual cracking is simple comparisons between encrypted text with known values and the data you are attacking.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339948</id>
	<title>Re:Good thing they're going to use open source</title>
	<author>digitalchinky</author>
	<datestamp>1260021060000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>In most parts of the world the telco's tend to microwave all their cell towers back to the exchange. It's cheaper to do it this way.</p><p>With a small investment (a couple of hundred $USD) on Ebay for some receive gear, modems, and data capture cards, your average enthusiast has absolutely no need for decryption of GSM. The only point encryption takes place is between the phone and the tower. The microwave links are not encrypted and are virtually always conveyed using E1 / T1 transmissions - maybe sometimes replace the 1 with a bigger number in congested areas.</p><p>The only hard part is picking out your target, but this is hard anyway, even if you can manage decryption while the call is still in progress. (Frequency hopping and sheer number of users) Also at the trunk level, the out of band signaling (SS7) doesn't tell you where the phone call actually is (which timeslot), so you'll have to either record everything and go through it manually, or use some kind of fudged analysis to guess based on activity in the SS7 and what you see in the trunk. Or... You might just be voyeuristic, in it just for the gossip / phone sex / ambulance chasing / whatever, so none of the above matters.</p></htmltext>
<tokenext>In most parts of the world the telco 's tend to microwave all their cell towers back to the exchange .
It 's cheaper to do it this way.With a small investment ( a couple of hundred $ USD ) on Ebay for some receive gear , modems , and data capture cards , your average enthusiast has absolutely no need for decryption of GSM .
The only point encryption takes place is between the phone and the tower .
The microwave links are not encrypted and are virtually always conveyed using E1 / T1 transmissions - maybe sometimes replace the 1 with a bigger number in congested areas.The only hard part is picking out your target , but this is hard anyway , even if you can manage decryption while the call is still in progress .
( Frequency hopping and sheer number of users ) Also at the trunk level , the out of band signaling ( SS7 ) does n't tell you where the phone call actually is ( which timeslot ) , so you 'll have to either record everything and go through it manually , or use some kind of fudged analysis to guess based on activity in the SS7 and what you see in the trunk .
Or... You might just be voyeuristic , in it just for the gossip / phone sex / ambulance chasing / whatever , so none of the above matters .</tokentext>
<sentencetext>In most parts of the world the telco's tend to microwave all their cell towers back to the exchange.
It's cheaper to do it this way.With a small investment (a couple of hundred $USD) on Ebay for some receive gear, modems, and data capture cards, your average enthusiast has absolutely no need for decryption of GSM.
The only point encryption takes place is between the phone and the tower.
The microwave links are not encrypted and are virtually always conveyed using E1 / T1 transmissions - maybe sometimes replace the 1 with a bigger number in congested areas.The only hard part is picking out your target, but this is hard anyway, even if you can manage decryption while the call is still in progress.
(Frequency hopping and sheer number of users) Also at the trunk level, the out of band signaling (SS7) doesn't tell you where the phone call actually is (which timeslot), so you'll have to either record everything and go through it manually, or use some kind of fudged analysis to guess based on activity in the SS7 and what you see in the trunk.
Or... You might just be voyeuristic, in it just for the gossip / phone sex / ambulance chasing / whatever, so none of the above matters.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338350</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30352488</id>
	<title>GSM@Home?</title>
	<author>Aizenmyou</author>
	<datestamp>1260198900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I can see it now...</htmltext>
<tokenext>I can see it now.. .</tokentext>
<sentencetext>I can see it now...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338886</id>
	<title>Re:Good thing they're going to use open source</title>
	<author>Anonymous</author>
	<datestamp>1260012720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Who wants it cracked in the first place? The only interests served are those of crooks and spys.</p></htmltext>
<tokenext>Who wants it cracked in the first place ?
The only interests served are those of crooks and spys .</tokentext>
<sentencetext>Who wants it cracked in the first place?
The only interests served are those of crooks and spys.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338350</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341816</id>
	<title>So sad, that humor is not with us...</title>
	<author>SuperKendall</author>
	<datestamp>1260090300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm really not sure how this was branded "Troll" as I meant the whole thing in jest.  Lighten up, fellow hackers!</p></htmltext>
<tokenext>I 'm really not sure how this was branded " Troll " as I meant the whole thing in jest .
Lighten up , fellow hackers !</tokentext>
<sentencetext>I'm really not sure how this was branded "Troll" as I meant the whole thing in jest.
Lighten up, fellow hackers!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339830</id>
	<title>again?</title>
	<author>cfriedt</author>
	<datestamp>1260020100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>GSM was rendered practically insecure a long time ago... I guess this is supposed to be some kind of demonstration of Nvidia's awesome computing power?</htmltext>
<tokenext>GSM was rendered practically insecure a long time ago... I guess this is supposed to be some kind of demonstration of Nvidia 's awesome computing power ?</tokentext>
<sentencetext>GSM was rendered practically insecure a long time ago... I guess this is supposed to be some kind of demonstration of Nvidia's awesome computing power?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338338</id>
	<title>Re:Incorrect time estimate? BOINC?</title>
	<author>baffler86</author>
	<datestamp>1260008280000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>This should definitely be done on public school computers. Free computing to the user and a tried and true method of distributed computing.</htmltext>
<tokenext>This should definitely be done on public school computers .
Free computing to the user and a tried and true method of distributed computing .</tokentext>
<sentencetext>This should definitely be done on public school computers.
Free computing to the user and a tried and true method of distributed computing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338298</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338350</id>
	<title>Good thing they're going to use open source</title>
	<author>Anonymous</author>
	<datestamp>1260008340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Nobody wants GSM Encryption broken if it's done using proprietary code. And if the general public is told this is illegal, just think of the free publicity for open source!</p></htmltext>
<tokenext>Nobody wants GSM Encryption broken if it 's done using proprietary code .
And if the general public is told this is illegal , just think of the free publicity for open source !</tokentext>
<sentencetext>Nobody wants GSM Encryption broken if it's done using proprietary code.
And if the general public is told this is illegal, just think of the free publicity for open source!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341788</id>
	<title>Already done?</title>
	<author>Anonymous</author>
	<datestamp>1260132960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Wasn't this done already by a bunch of folks using FPGA's with the GNUradio USRP?<br>This was a story on slashdot, quite a long time ago...</p><p>Someone else please bother to look it up and get mod points.<br>I'm too lazy to even create a slashdot account (have been for yeaaars)<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Was n't this done already by a bunch of folks using FPGA 's with the GNUradio USRP ? This was a story on slashdot , quite a long time ago...Someone else please bother to look it up and get mod points.I 'm too lazy to even create a slashdot account ( have been for yeaaars ) : )</tokentext>
<sentencetext>Wasn't this done already by a bunch of folks using FPGA's with the GNUradio USRP?This was a story on slashdot, quite a long time ago...Someone else please bother to look it up and get mod points.I'm too lazy to even create a slashdot account (have been for yeaaars) :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339204</id>
	<title>What - no Mac version?</title>
	<author>ctmurray</author>
	<datestamp>1260014940000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>I was disappointed when I saw no mention of a Mac version:<p><div class="quote"><p>The engineer has designed an open-source software program that participants in his A5/1 cracking project can install on their PCs and use to share the task of computing the lookup tables that make up the cryptography system.</p></div></div>
	</htmltext>
<tokenext>I was disappointed when I saw no mention of a Mac version : The engineer has designed an open-source software program that participants in his A5/1 cracking project can install on their PCs and use to share the task of computing the lookup tables that make up the cryptography system .</tokentext>
<sentencetext>I was disappointed when I saw no mention of a Mac version:The engineer has designed an open-source software program that participants in his A5/1 cracking project can install on their PCs and use to share the task of computing the lookup tables that make up the cryptography system.
	</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30345278
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338298
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30340696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30350002
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338312
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338366
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338298
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341816
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30347704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339816
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30342744
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338312
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30342906
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341088
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339948
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338350
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338602
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338354
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338886
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338350
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_05_1958251_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338296
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339124
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341088
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30342906
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30337980
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30340696
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30341816
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338350
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338886
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339948
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338000
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339816
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30339894
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30347704
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338432
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338174
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338602
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338296
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338354
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338312
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30342744
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30350002
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338366
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338298
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30345278
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338338
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338236
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_05_1958251.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_05_1958251.30338014
</commentlist>
</conversation>
