<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_01_29_0343233</id>
	<title>Parallel Algorithm Leads To Crypto Breakthrough</title>
	<author>timothy</author>
	<datestamp>1264771080000</datestamp>
	<htmltext><a href="http://hughpickens.com/" rel="nofollow">Hugh Pickens</a> writes <i>"Dr. Dobbs reports that a cracking algorithm using brute force methods can <a href="http://www.ddj.com/222600319">analyze the entire DES 56-bit keyspace with a throughput of over 280 billion keys per second</a>, the highest-known benchmark speeds for 56-bit DES decryption and can accomplish a key recovery that would take years to perform on a PC, even with GPU acceleration, in less than three days using a single, hardware-accelerated server with a cluster of 176 FPGAs. The massively parallel algorithm iteratively decrypts fixed-size blocks of data to find keys that decrypt into ASCII numbers.  Candidate keys that are found in this way can then be more thoroughly tested to determine which candidate key is correct."</i> <strong>Update by timothy, 2010-01-29 19:05 GMT:</strong> Reader Stefan Baumgart writes to point out prior <a href="http://en.wikipedia.org/wiki/Data\_Encryption\_Standard#Brute\_force\_attack">brute-force methods</a> using reprogrammable chips, including <a href="http://www.hyperelliptic.org/tanja/SHARCS/talks06/copacobana.pdf">Copacobana</a> (PDF), have achieved even shorter cracking times for DES-56. See also this <a href="//news.slashdot.org/story/05/09/08/1653245/Brute-Force&amp;from=rss">2005 book review of  <em>Brute Force</em></a>, about the EFF's distributed DES-breaking effort that succeeded in 1997 in cracking a DES-encrypted message.</htmltext>
<tokenext>Hugh Pickens writes " Dr. Dobbs reports that a cracking algorithm using brute force methods can analyze the entire DES 56-bit keyspace with a throughput of over 280 billion keys per second , the highest-known benchmark speeds for 56-bit DES decryption and can accomplish a key recovery that would take years to perform on a PC , even with GPU acceleration , in less than three days using a single , hardware-accelerated server with a cluster of 176 FPGAs .
The massively parallel algorithm iteratively decrypts fixed-size blocks of data to find keys that decrypt into ASCII numbers .
Candidate keys that are found in this way can then be more thoroughly tested to determine which candidate key is correct .
" Update by timothy , 2010-01-29 19 : 05 GMT : Reader Stefan Baumgart writes to point out prior brute-force methods using reprogrammable chips , including Copacobana ( PDF ) , have achieved even shorter cracking times for DES-56 .
See also this 2005 book review of Brute Force , about the EFF 's distributed DES-breaking effort that succeeded in 1997 in cracking a DES-encrypted message .</tokentext>
<sentencetext>Hugh Pickens writes "Dr. Dobbs reports that a cracking algorithm using brute force methods can analyze the entire DES 56-bit keyspace with a throughput of over 280 billion keys per second, the highest-known benchmark speeds for 56-bit DES decryption and can accomplish a key recovery that would take years to perform on a PC, even with GPU acceleration, in less than three days using a single, hardware-accelerated server with a cluster of 176 FPGAs.
The massively parallel algorithm iteratively decrypts fixed-size blocks of data to find keys that decrypt into ASCII numbers.
Candidate keys that are found in this way can then be more thoroughly tested to determine which candidate key is correct.
" Update by timothy, 2010-01-29 19:05 GMT: Reader Stefan Baumgart writes to point out prior brute-force methods using reprogrammable chips, including Copacobana (PDF), have achieved even shorter cracking times for DES-56.
See also this 2005 book review of  Brute Force, about the EFF's distributed DES-breaking effort that succeeded in 1997 in cracking a DES-encrypted message.</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949168</id>
	<title>Re:searching for ASCII</title>
	<author>Sir\_Lewk</author>
	<datestamp>1264779780000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>I know you are joking, but I think it should be pointed out that there is no reason this technique can't look for something other than ASCII chars.  Most binary files have predictable sequences of bits in them, often some sort of header.</p></htmltext>
<tokenext>I know you are joking , but I think it should be pointed out that there is no reason this technique ca n't look for something other than ASCII chars .
Most binary files have predictable sequences of bits in them , often some sort of header .</tokentext>
<sentencetext>I know you are joking, but I think it should be pointed out that there is no reason this technique can't look for something other than ASCII chars.
Most binary files have predictable sequences of bits in them, often some sort of header.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418</id>
	<title>What?</title>
	<author>Anonymous</author>
	<datestamp>1264775400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p><i>Parallel Algorithm Leads To Crypto Breakthrough</i></p><p>Crypto Breakthrough? Huh? What's that supposed to mean?</p><p>I mean, yes, his DES-cracking hardware is about 800x faster than a PC. Where's the "Crypto Breakthrough"?</p></htmltext>
<tokenext>Parallel Algorithm Leads To Crypto BreakthroughCrypto Breakthrough ?
Huh ? What 's that supposed to mean ? I mean , yes , his DES-cracking hardware is about 800x faster than a PC .
Where 's the " Crypto Breakthrough " ?</tokentext>
<sentencetext>Parallel Algorithm Leads To Crypto BreakthroughCrypto Breakthrough?
Huh? What's that supposed to mean?I mean, yes, his DES-cracking hardware is about 800x faster than a PC.
Where's the "Crypto Breakthrough"?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951998</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>onionman</author>
	<datestamp>1264790280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Your point is correct.  You have to have additional information about the traffic.  Often this comes in the form of frequency analysis of the trial decryption, or a known block of plaintext that is part of the formatting or protocol of the message (the standard example is the date of the message that the Nazi's often placed in their Enigma encrypted messages; if you know the date of the intercept, then you've got a pretty good guess for the plaintext for the first half dozen letter, so it's easier to test if a key is correct.)</p></htmltext>
<tokenext>Your point is correct .
You have to have additional information about the traffic .
Often this comes in the form of frequency analysis of the trial decryption , or a known block of plaintext that is part of the formatting or protocol of the message ( the standard example is the date of the message that the Nazi 's often placed in their Enigma encrypted messages ; if you know the date of the intercept , then you 've got a pretty good guess for the plaintext for the first half dozen letter , so it 's easier to test if a key is correct .
)</tokentext>
<sentencetext>Your point is correct.
You have to have additional information about the traffic.
Often this comes in the form of frequency analysis of the trial decryption, or a known block of plaintext that is part of the formatting or protocol of the message (the standard example is the date of the message that the Nazi's often placed in their Enigma encrypted messages; if you know the date of the intercept, then you've got a pretty good guess for the plaintext for the first half dozen letter, so it's easier to test if a key is correct.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949582</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>owlstead</author>
	<datestamp>1264781580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Many encryption schemes (for secure messaging, say SSL) include a MAC or HMAC (secure checksum) with a *different* session key. So finding the MAC key is not always the same as finding the encryption key.</p><p>You know the password is correct by generating a key from a password (say, using PKCS#5 password based encryption key generation scheme), and sending back an encrypted challenge. Using DES for this scheme is a terrible idea (known plaintext - all the encrypted "characters" are known).</p><p>Anyway, most encrypted data (not passwords, they are normally not encrypted) is data wrapped in either ASN.1 DER encoded structures (CMS or PKCS#7) or (e.g.) XML encoded structures. Then there is the padding of the last block which is also generally known. Knowing the (partial) plain text of some of the encrypted blocks is simply not an issue.</p><p>Yes, you can encrypt twice, if needed with two different algorithms. Yes, this would mean that plain text is hard to detect. If you use the same key and the same algorithm, double encryption is probably cryptographically slightly worse compared to simply increasing the number of rounds of the algorithm. There is simply no good substitute for Increasing the key length and using a good cryptographic algorithm like AES (for any key size).</p></htmltext>
<tokenext>Many encryption schemes ( for secure messaging , say SSL ) include a MAC or HMAC ( secure checksum ) with a * different * session key .
So finding the MAC key is not always the same as finding the encryption key.You know the password is correct by generating a key from a password ( say , using PKCS # 5 password based encryption key generation scheme ) , and sending back an encrypted challenge .
Using DES for this scheme is a terrible idea ( known plaintext - all the encrypted " characters " are known ) .Anyway , most encrypted data ( not passwords , they are normally not encrypted ) is data wrapped in either ASN.1 DER encoded structures ( CMS or PKCS # 7 ) or ( e.g .
) XML encoded structures .
Then there is the padding of the last block which is also generally known .
Knowing the ( partial ) plain text of some of the encrypted blocks is simply not an issue.Yes , you can encrypt twice , if needed with two different algorithms .
Yes , this would mean that plain text is hard to detect .
If you use the same key and the same algorithm , double encryption is probably cryptographically slightly worse compared to simply increasing the number of rounds of the algorithm .
There is simply no good substitute for Increasing the key length and using a good cryptographic algorithm like AES ( for any key size ) .</tokentext>
<sentencetext>Many encryption schemes (for secure messaging, say SSL) include a MAC or HMAC (secure checksum) with a *different* session key.
So finding the MAC key is not always the same as finding the encryption key.You know the password is correct by generating a key from a password (say, using PKCS#5 password based encryption key generation scheme), and sending back an encrypted challenge.
Using DES for this scheme is a terrible idea (known plaintext - all the encrypted "characters" are known).Anyway, most encrypted data (not passwords, they are normally not encrypted) is data wrapped in either ASN.1 DER encoded structures (CMS or PKCS#7) or (e.g.
) XML encoded structures.
Then there is the padding of the last block which is also generally known.
Knowing the (partial) plain text of some of the encrypted blocks is simply not an issue.Yes, you can encrypt twice, if needed with two different algorithms.
Yes, this would mean that plain text is hard to detect.
If you use the same key and the same algorithm, double encryption is probably cryptographically slightly worse compared to simply increasing the number of rounds of the algorithm.
There is simply no good substitute for Increasing the key length and using a good cryptographic algorithm like AES (for any key size).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949110</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>SlideRuleGuy</author>
	<datestamp>1264779540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Folks need to use Rivest's Package Transform (i.e., all-or-nothing encryption).  This increases the difficulty by forcing a cryptanalyst to decrypt an entire (multi-block) message instead of just individual blocks, before looking for plaintext.
<br> <br>
<a href="http://en.wikipedia.org/wiki/All-or-nothing\_transform" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/All-or-nothing\_transform</a> [wikipedia.org]
<br> <br>
(Or just switch to AES...duh.)</htmltext>
<tokenext>Folks need to use Rivest 's Package Transform ( i.e. , all-or-nothing encryption ) .
This increases the difficulty by forcing a cryptanalyst to decrypt an entire ( multi-block ) message instead of just individual blocks , before looking for plaintext .
http : //en.wikipedia.org/wiki/All-or-nothing \ _transform [ wikipedia.org ] ( Or just switch to AES...duh .
)</tokentext>
<sentencetext>Folks need to use Rivest's Package Transform (i.e., all-or-nothing encryption).
This increases the difficulty by forcing a cryptanalyst to decrypt an entire (multi-block) message instead of just individual blocks, before looking for plaintext.
http://en.wikipedia.org/wiki/All-or-nothing\_transform [wikipedia.org]
 
(Or just switch to AES...duh.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951484</id>
	<title>Re:Practical value</title>
	<author>Lisandro</author>
	<datestamp>1264788540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>DES has little to do with Blowfish, in particular, besides being both block cyphers.</htmltext>
<tokenext>DES has little to do with Blowfish , in particular , besides being both block cyphers .</tokentext>
<sentencetext>DES has little to do with Blowfish, in particular, besides being both block cyphers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949166</id>
	<title>Re:searching for ASCII</title>
	<author>Anonymous</author>
	<datestamp>1264779780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Question is, what do you have to hide? I can only assume you are a criminal.</p></htmltext>
<tokenext>Question is , what do you have to hide ?
I can only assume you are a criminal .</tokentext>
<sentencetext>Question is, what do you have to hide?
I can only assume you are a criminal.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948626</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>noidentity</author>
	<datestamp>1264776600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext>Any realistic encryption format will include verification information (a checksum at the very least) so the decrypter knows that it was successful. Otherwise it wouldn't even be able to tell you that you mistyped your password.</htmltext>
<tokenext>Any realistic encryption format will include verification information ( a checksum at the very least ) so the decrypter knows that it was successful .
Otherwise it would n't even be able to tell you that you mistyped your password .</tokentext>
<sentencetext>Any realistic encryption format will include verification information (a checksum at the very least) so the decrypter knows that it was successful.
Otherwise it wouldn't even be able to tell you that you mistyped your password.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949746</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Dracolytch</author>
	<datestamp>1264782240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Execpt the vast, vast, vast majority of data that's sent isn't random at all. In fact, it's extremely not-random. If you open a file in a hex editor (even a binary instead of ascii file), there are patterns, there is text, there are markers to show you what you have. Heck, in many files, the first 4-8 bytes of the file will tell you exactly what kind of file it is. While it's not a super-easy problem, it's easier than you're making it out to be.</p><p>~D</p></htmltext>
<tokenext>Execpt the vast , vast , vast majority of data that 's sent is n't random at all .
In fact , it 's extremely not-random .
If you open a file in a hex editor ( even a binary instead of ascii file ) , there are patterns , there is text , there are markers to show you what you have .
Heck , in many files , the first 4-8 bytes of the file will tell you exactly what kind of file it is .
While it 's not a super-easy problem , it 's easier than you 're making it out to be. ~ D</tokentext>
<sentencetext>Execpt the vast, vast, vast majority of data that's sent isn't random at all.
In fact, it's extremely not-random.
If you open a file in a hex editor (even a binary instead of ascii file), there are patterns, there is text, there are markers to show you what you have.
Heck, in many files, the first 4-8 bytes of the file will tell you exactly what kind of file it is.
While it's not a super-easy problem, it's easier than you're making it out to be.~D</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948602</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264776480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's a really interesting question.  I'm not a math or cryptography person, so I'm just guessing here, but I bet you could some how measure how disordered the data stream was and make a guess about weather or not it was encrypted.  It seems that encrypted data should also have some level of order to it.  If you use something like rot-13 (which I know is a cypher not strictly encryption) to cypher an english message you can do some simple statistical analysis and make some intelligent guesses as to wich letter cypher letter corresponds to 'e' and 'a' and 'z' and so forth.
</p><p>Perhaps some sort of similar thinking can be applied to a chunk of data to determine if it's just random junk or has something embedded in it. Are there any crypto or math people out there that can comment on this?
</p><p>The OP brings up an interesting point, of knowing when your data is <b>actually</b> decrypted.  For plain text, it should be pretty easy to just do a quick scan for english/french/whatever words, for pictures, it would be fairly easy to look for things like jpeg headers. But what if it's some sort of proprietary data or just a chunk of a file?  How do you know if you're successful?</p></htmltext>
<tokenext>That 's a really interesting question .
I 'm not a math or cryptography person , so I 'm just guessing here , but I bet you could some how measure how disordered the data stream was and make a guess about weather or not it was encrypted .
It seems that encrypted data should also have some level of order to it .
If you use something like rot-13 ( which I know is a cypher not strictly encryption ) to cypher an english message you can do some simple statistical analysis and make some intelligent guesses as to wich letter cypher letter corresponds to 'e ' and 'a ' and 'z ' and so forth .
Perhaps some sort of similar thinking can be applied to a chunk of data to determine if it 's just random junk or has something embedded in it .
Are there any crypto or math people out there that can comment on this ?
The OP brings up an interesting point , of knowing when your data is actually decrypted .
For plain text , it should be pretty easy to just do a quick scan for english/french/whatever words , for pictures , it would be fairly easy to look for things like jpeg headers .
But what if it 's some sort of proprietary data or just a chunk of a file ?
How do you know if you 're successful ?</tokentext>
<sentencetext>That's a really interesting question.
I'm not a math or cryptography person, so I'm just guessing here, but I bet you could some how measure how disordered the data stream was and make a guess about weather or not it was encrypted.
It seems that encrypted data should also have some level of order to it.
If you use something like rot-13 (which I know is a cypher not strictly encryption) to cypher an english message you can do some simple statistical analysis and make some intelligent guesses as to wich letter cypher letter corresponds to 'e' and 'a' and 'z' and so forth.
Perhaps some sort of similar thinking can be applied to a chunk of data to determine if it's just random junk or has something embedded in it.
Are there any crypto or math people out there that can comment on this?
The OP brings up an interesting point, of knowing when your data is actually decrypted.
For plain text, it should be pretty easy to just do a quick scan for english/french/whatever words, for pictures, it would be fairly easy to look for things like jpeg headers.
But what if it's some sort of proprietary data or just a chunk of a file?
How do you know if you're successful?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948616</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Arancaytar</author>
	<datestamp>1264776540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's easy - the (uncompressed) clear text is going to be considerably <a href="http://en.wikipedia.org/wiki/Entropy\_(information\_theory)" title="wikipedia.org">less entropic</a> [wikipedia.org] than average, and  even most compression algorithms cannot raise the entropy to the same level as that of a random message.</p><p>The key-space in DES 56 (ie, 2^56) is considerably smaller than the number of possible messages with that length (might be 2^(1000*x) for a text multiple kB message). If one of these 2^56 keys decrypts the message to a coherent clear text out of 2^1000, it's extremely unlikely to be a chance result.</p><p>If you encrypted random data, then it would take a long while, but after searching the whole key space the eavesdropper would eventually conclude that there is no clear text.</p><p>You were probably thinking of a one-time-pad, where the key contains exactly as many bits of random noise as the message is long. That gives every clear message of the right length exactly the same likelihood, and really does make it impossible to know when you've succeeded - or to determine whether the message is random noise or not.</p></htmltext>
<tokenext>That 's easy - the ( uncompressed ) clear text is going to be considerably less entropic [ wikipedia.org ] than average , and even most compression algorithms can not raise the entropy to the same level as that of a random message.The key-space in DES 56 ( ie , 2 ^ 56 ) is considerably smaller than the number of possible messages with that length ( might be 2 ^ ( 1000 * x ) for a text multiple kB message ) .
If one of these 2 ^ 56 keys decrypts the message to a coherent clear text out of 2 ^ 1000 , it 's extremely unlikely to be a chance result.If you encrypted random data , then it would take a long while , but after searching the whole key space the eavesdropper would eventually conclude that there is no clear text.You were probably thinking of a one-time-pad , where the key contains exactly as many bits of random noise as the message is long .
That gives every clear message of the right length exactly the same likelihood , and really does make it impossible to know when you 've succeeded - or to determine whether the message is random noise or not .</tokentext>
<sentencetext>That's easy - the (uncompressed) clear text is going to be considerably less entropic [wikipedia.org] than average, and  even most compression algorithms cannot raise the entropy to the same level as that of a random message.The key-space in DES 56 (ie, 2^56) is considerably smaller than the number of possible messages with that length (might be 2^(1000*x) for a text multiple kB message).
If one of these 2^56 keys decrypts the message to a coherent clear text out of 2^1000, it's extremely unlikely to be a chance result.If you encrypted random data, then it would take a long while, but after searching the whole key space the eavesdropper would eventually conclude that there is no clear text.You were probably thinking of a one-time-pad, where the key contains exactly as many bits of random noise as the message is long.
That gives every clear message of the right length exactly the same likelihood, and really does make it impossible to know when you've succeeded - or to determine whether the message is random noise or not.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948340</id>
	<title>Svefg cbfg!</title>
	<author>Anonymous</author>
	<datestamp>1264774860000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Svefg cbfg!</p></htmltext>
<tokenext>Svefg cbfg !</tokentext>
<sentencetext>Svefg cbfg!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950648</id>
	<title>Re:What?</title>
	<author>DigitAl56K</author>
	<datestamp>1264785720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>"What?" indeed.</p><p>This is <b>exactly the same technique as the EFF DES cracker used in 1998</b>, except using FGPAs instead of custom chips.</p><p><a href="http://w2.eff.org/Privacy/Crypto/Crypto\_misc/DESCracker/HTML/19980716\_eff\_des\_faq.html#howsitwork" title="eff.org">http://w2.eff.org/Privacy/Crypto/Crypto\_misc/DESCracker/HTML/19980716\_eff\_des\_faq.html#howsitwork</a> [eff.org]</p></htmltext>
<tokenext>" What ?
" indeed.This is exactly the same technique as the EFF DES cracker used in 1998 , except using FGPAs instead of custom chips.http : //w2.eff.org/Privacy/Crypto/Crypto \ _misc/DESCracker/HTML/19980716 \ _eff \ _des \ _faq.html # howsitwork [ eff.org ]</tokentext>
<sentencetext>"What?
" indeed.This is exactly the same technique as the EFF DES cracker used in 1998, except using FGPAs instead of custom chips.http://w2.eff.org/Privacy/Crypto/Crypto\_misc/DESCracker/HTML/19980716\_eff\_des\_faq.html#howsitwork [eff.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950338</id>
	<title>Re:What?</title>
	<author>Anonymous</author>
	<datestamp>1264784580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's hardly 800x faster!</p><p>The project uses a cluster of 100+ FPGAs.  It's not really a fair comparison to put up a single PC against a cluster of custom logic on FPGAs.  The result that one FPGA can process 1.6 billion blocks/sec versus a CPU/GPU which can only perform 200+ million is the interesting part.</p><p>I would like to see the power/performance tradeoff of GPUs vs. FPGAs.</p></htmltext>
<tokenext>It 's hardly 800x faster ! The project uses a cluster of 100 + FPGAs .
It 's not really a fair comparison to put up a single PC against a cluster of custom logic on FPGAs .
The result that one FPGA can process 1.6 billion blocks/sec versus a CPU/GPU which can only perform 200 + million is the interesting part.I would like to see the power/performance tradeoff of GPUs vs. FPGAs .</tokentext>
<sentencetext>It's hardly 800x faster!The project uses a cluster of 100+ FPGAs.
It's not really a fair comparison to put up a single PC against a cluster of custom logic on FPGAs.
The result that one FPGA can process 1.6 billion blocks/sec versus a CPU/GPU which can only perform 200+ million is the interesting part.I would like to see the power/performance tradeoff of GPUs vs. FPGAs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264776600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Even if it's ASCII or a picture, just encrypt it twice.</p></div><p>I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.  Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted?  What would happen if you encrypted over and over using the same key?</p></div>
	</htmltext>
<tokenext>Even if it 's ASCII or a picture , just encrypt it twice.I 've always wondered what would happen if you were to encrypt a file over and over again , with different keys .
Would that lead to any greater security , or would somehow leave more and more obvious clues as to how the data was encrypted ?
What would happen if you encrypted over and over using the same key ?</tokentext>
<sentencetext>Even if it's ASCII or a picture, just encrypt it twice.I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.
Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted?
What would happen if you encrypted over and over using the same key?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949140</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>TheRaven64</author>
	<datestamp>1264779660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The canonical example of a bad cypher is an XOR cypher, where every bit in the input stream is XOR'd with a key.  If you do this twice, with two separate keys, then you have done the equivalent of XOR it once with the key generated by XORing the two keys.  As such, it is no more secure (but also no less secure).</p><p>
With a perfect cypher, there is no relationship between the two applications, so if you encrypt it twice then you double the amount of effort required to crack it.  However, for most decent cyphers the difficulty of decrypting it is roughly proportional to the length of the key, so adding one bit to the key length gives you as much security as encrypting it twice.  </p><p>
The 3DES algorithm uses three 56-bit keys, but is much easier to break than using DES with one 168-bit key.  It was created because you can use it with DES-accelerating hardware (at a third of the speed of single DES), while using DES with a longer key would typically require new hardware.  </p><p>
Of course, this isn't always the case.  There are some attacks that take less time on the 192-bit key version of AES turns out to be harder to crack than the 256-bit key version.</p></htmltext>
<tokenext>The canonical example of a bad cypher is an XOR cypher , where every bit in the input stream is XOR 'd with a key .
If you do this twice , with two separate keys , then you have done the equivalent of XOR it once with the key generated by XORing the two keys .
As such , it is no more secure ( but also no less secure ) .
With a perfect cypher , there is no relationship between the two applications , so if you encrypt it twice then you double the amount of effort required to crack it .
However , for most decent cyphers the difficulty of decrypting it is roughly proportional to the length of the key , so adding one bit to the key length gives you as much security as encrypting it twice .
The 3DES algorithm uses three 56-bit keys , but is much easier to break than using DES with one 168-bit key .
It was created because you can use it with DES-accelerating hardware ( at a third of the speed of single DES ) , while using DES with a longer key would typically require new hardware .
Of course , this is n't always the case .
There are some attacks that take less time on the 192-bit key version of AES turns out to be harder to crack than the 256-bit key version .</tokentext>
<sentencetext>The canonical example of a bad cypher is an XOR cypher, where every bit in the input stream is XOR'd with a key.
If you do this twice, with two separate keys, then you have done the equivalent of XOR it once with the key generated by XORing the two keys.
As such, it is no more secure (but also no less secure).
With a perfect cypher, there is no relationship between the two applications, so if you encrypt it twice then you double the amount of effort required to crack it.
However, for most decent cyphers the difficulty of decrypting it is roughly proportional to the length of the key, so adding one bit to the key length gives you as much security as encrypting it twice.
The 3DES algorithm uses three 56-bit keys, but is much easier to break than using DES with one 168-bit key.
It was created because you can use it with DES-accelerating hardware (at a third of the speed of single DES), while using DES with a longer key would typically require new hardware.
Of course, this isn't always the case.
There are some attacks that take less time on the 192-bit key version of AES turns out to be harder to crack than the 256-bit key version.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948982</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>bobdotorg</author>
	<datestamp>1264778760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><blockquote><div><p>Even if it's ASCII or a picture, just encrypt it twice.</p></div></blockquote><p>I've always wondered what would happen if you were to encrypt a file over and over again</p></div></blockquote><p>Not always better.  For example, the text you are reading now was encrypted with ROT13.  Twice.</p></div>
	</htmltext>
<tokenext>Even if it 's ASCII or a picture , just encrypt it twice.I 've always wondered what would happen if you were to encrypt a file over and over againNot always better .
For example , the text you are reading now was encrypted with ROT13 .
Twice .</tokentext>
<sentencetext>Even if it's ASCII or a picture, just encrypt it twice.I've always wondered what would happen if you were to encrypt a file over and over againNot always better.
For example, the text you are reading now was encrypted with ROT13.
Twice.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949958</id>
	<title>Re:Practical value</title>
	<author>I cant believe its n</author>
	<datestamp>1264783140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>RACF passtickets on IBM mainframes are based on DES. Only valid for a few minutes though.</htmltext>
<tokenext>RACF passtickets on IBM mainframes are based on DES .
Only valid for a few minutes though .</tokentext>
<sentencetext>RACF passtickets on IBM mainframes are based on DES.
Only valid for a few minutes though.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948536</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Lord Byron II</author>
	<datestamp>1264776120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>Exactly right.</p><p>Properly encrypted data should be indistinguishable from random noise.</p><p>The pigeon hole principle applies to the "decrypted" data. Say you have 16 bytes of data protected by a 16-byte key. Then, there will be lots of keys that produce non-random "decrypted" sequences. But, if you have 1GB of data and a 16-byte key, then there is likely (depending on the nature of the underlying data) only one key that will produce the decrypted data.</p><p>It's similar to why there can't exist a generic compression algorithm that *always* shrinks a file.</p></htmltext>
<tokenext>Exactly right.Properly encrypted data should be indistinguishable from random noise.The pigeon hole principle applies to the " decrypted " data .
Say you have 16 bytes of data protected by a 16-byte key .
Then , there will be lots of keys that produce non-random " decrypted " sequences .
But , if you have 1GB of data and a 16-byte key , then there is likely ( depending on the nature of the underlying data ) only one key that will produce the decrypted data.It 's similar to why there ca n't exist a generic compression algorithm that * always * shrinks a file .</tokentext>
<sentencetext>Exactly right.Properly encrypted data should be indistinguishable from random noise.The pigeon hole principle applies to the "decrypted" data.
Say you have 16 bytes of data protected by a 16-byte key.
Then, there will be lots of keys that produce non-random "decrypted" sequences.
But, if you have 1GB of data and a 16-byte key, then there is likely (depending on the nature of the underlying data) only one key that will produce the decrypted data.It's similar to why there can't exist a generic compression algorithm that *always* shrinks a file.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948614</id>
	<title>Re:Practical value</title>
	<author>Anonymous</author>
	<datestamp>1264776540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>DES algorithm is quite similar to AES and Blowfish.</p></div></blockquote><p>In that they're both block ciphers, yes. That's where the similarity ends; AES doesn't even use a Feistel network. Your comparison is like saying that a flintlock rifle is just like an M1 tank. In other words, you have absolutely no clue what you're talking about.</p></div>
	</htmltext>
<tokenext>DES algorithm is quite similar to AES and Blowfish.In that they 're both block ciphers , yes .
That 's where the similarity ends ; AES does n't even use a Feistel network .
Your comparison is like saying that a flintlock rifle is just like an M1 tank .
In other words , you have absolutely no clue what you 're talking about .</tokentext>
<sentencetext>DES algorithm is quite similar to AES and Blowfish.In that they're both block ciphers, yes.
That's where the similarity ends; AES doesn't even use a Feistel network.
Your comparison is like saying that a flintlock rifle is just like an M1 tank.
In other words, you have absolutely no clue what you're talking about.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30954072</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Impy the Impiuos Imp</author>
	<datestamp>1264756020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; Apart form the trivial case where some ASCII, or a picture pops up, how can a decrypter know when the<br>&gt; block or stream of apparently random data has been decrypted?</p><p>Well, in this case they're talking about a 56-bit almost-prime number that factors into two primes roughly half the size.  The encryption relies on this, so if you can do it, the decoding is straightforward.</p><p>As for a brute force method, there are probably algorithms that can guestimate based on how far from random your candidate decoding is, the further the better.</p><p>Also, I'm sure the CIA has computers that crank everything through every known language, backwards and forwards, with other simpler, intermediate encodings applied, vowels left out, Soundex algorithm applied and not, etc. et al.</p><p>Of course that, in and of itself, is quite a significant project.  Anyway, if I had their resources, that's what I'd do.</p></htmltext>
<tokenext>&gt; Apart form the trivial case where some ASCII , or a picture pops up , how can a decrypter know when the &gt; block or stream of apparently random data has been decrypted ? Well , in this case they 're talking about a 56-bit almost-prime number that factors into two primes roughly half the size .
The encryption relies on this , so if you can do it , the decoding is straightforward.As for a brute force method , there are probably algorithms that can guestimate based on how far from random your candidate decoding is , the further the better.Also , I 'm sure the CIA has computers that crank everything through every known language , backwards and forwards , with other simpler , intermediate encodings applied , vowels left out , Soundex algorithm applied and not , etc .
et al.Of course that , in and of itself , is quite a significant project .
Anyway , if I had their resources , that 's what I 'd do .</tokentext>
<sentencetext>&gt; Apart form the trivial case where some ASCII, or a picture pops up, how can a decrypter know when the&gt; block or stream of apparently random data has been decrypted?Well, in this case they're talking about a 56-bit almost-prime number that factors into two primes roughly half the size.
The encryption relies on this, so if you can do it, the decoding is straightforward.As for a brute force method, there are probably algorithms that can guestimate based on how far from random your candidate decoding is, the further the better.Also, I'm sure the CIA has computers that crank everything through every known language, backwards and forwards, with other simpler, intermediate encodings applied, vowels left out, Soundex algorithm applied and not, etc.
et al.Of course that, in and of itself, is quite a significant project.
Anyway, if I had their resources, that's what I'd do.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949302</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Lord Ender</author>
	<datestamp>1264780320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The answer to your question is implementation-specific.</p><p>If you're cracking encrypted email, you know you're looking for plain text, so that test is easy. Cracking TrueCrypt partitions? Use whatever algorithm TC uses to determine whether or not a password matches (TC has some deterministic means of distinguishing this, for use in its plausible deniability feature).</p><p>Cracking SSL? Look for the one which decrypts to HTTP.</p><p>Cracking general disk encryption products? Look for filesystem structures.</p><p>The only time the problem you mention could trip you up is when you have no idea what format the underlying data is in. In that case, you can test for entropy or try some other tricks.</p></htmltext>
<tokenext>The answer to your question is implementation-specific.If you 're cracking encrypted email , you know you 're looking for plain text , so that test is easy .
Cracking TrueCrypt partitions ?
Use whatever algorithm TC uses to determine whether or not a password matches ( TC has some deterministic means of distinguishing this , for use in its plausible deniability feature ) .Cracking SSL ?
Look for the one which decrypts to HTTP.Cracking general disk encryption products ?
Look for filesystem structures.The only time the problem you mention could trip you up is when you have no idea what format the underlying data is in .
In that case , you can test for entropy or try some other tricks .</tokentext>
<sentencetext>The answer to your question is implementation-specific.If you're cracking encrypted email, you know you're looking for plain text, so that test is easy.
Cracking TrueCrypt partitions?
Use whatever algorithm TC uses to determine whether or not a password matches (TC has some deterministic means of distinguishing this, for use in its plausible deniability feature).Cracking SSL?
Look for the one which decrypts to HTTP.Cracking general disk encryption products?
Look for filesystem structures.The only time the problem you mention could trip you up is when you have no idea what format the underlying data is in.
In that case, you can test for entropy or try some other tricks.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948360</id>
	<title>Should be building standardised FPGAs into systems</title>
	<author>Colin Smith</author>
	<datestamp>1264775040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Apps could load a custom config into the chip to run faster.</p><p>
&nbsp;</p></htmltext>
<tokenext>Apps could load a custom config into the chip to run faster .
 </tokentext>
<sentencetext>Apps could load a custom config into the chip to run faster.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948866</id>
	<title>Re:searching for ASCII</title>
	<author>Anonymous</author>
	<datestamp>1264778040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yeah, so how again do you encode your messages to have an entropy close enough to random noise? Encypting *twice*?</p></htmltext>
<tokenext>Yeah , so how again do you encode your messages to have an entropy close enough to random noise ?
Encypting * twice * ?</tokentext>
<sentencetext>Yeah, so how again do you encode your messages to have an entropy close enough to random noise?
Encypting *twice*?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949382</id>
	<title>Re:Practical value</title>
	<author>aunt edna</author>
	<datestamp>1264780680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><blockquote><div><p>DES algorithm is quite similar to AES and Blowfish.</p></div></blockquote><p>In that they're both block ciphers, yes. That's where the similarity ends; AES doesn't even use a Feistel network. Your comparison is like saying that a flintlock rifle is just like an M1 tank. In other words, you have absolutely no clue what you're talking about.</p></div><p>Hey, try a dose of maturity -- you might get to like it.<br>And then, you just might learn to behave better when replying to a post.<br>Or not.</p></div>
	</htmltext>
<tokenext>DES algorithm is quite similar to AES and Blowfish.In that they 're both block ciphers , yes .
That 's where the similarity ends ; AES does n't even use a Feistel network .
Your comparison is like saying that a flintlock rifle is just like an M1 tank .
In other words , you have absolutely no clue what you 're talking about.Hey , try a dose of maturity -- you might get to like it.And then , you just might learn to behave better when replying to a post.Or not .</tokentext>
<sentencetext>DES algorithm is quite similar to AES and Blowfish.In that they're both block ciphers, yes.
That's where the similarity ends; AES doesn't even use a Feistel network.
Your comparison is like saying that a flintlock rifle is just like an M1 tank.
In other words, you have absolutely no clue what you're talking about.Hey, try a dose of maturity -- you might get to like it.And then, you just might learn to behave better when replying to a post.Or not.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952526</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Peter Amstutz</author>
	<datestamp>1264792200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Even if it's ASCII or a picture, just encrypt it twice.</p></div><p>I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.</p><p>You get <a href="http://en.wikipedia.org/wiki/Triple\_DES" title="wikipedia.org" rel="nofollow">Triple-DES</a> [wikipedia.org].</p><p>Also, consider that encryption algorithms are not magic.  Having no distinguishable pattern to attacker is the goal, but the data is not actually random!  Encryption comes down to applying a set of mathematical transformations on your data which leaves "fingerprints" in the cyphertext if you know what to look for.  Applying more than one algorithm or the same algorithm more than once at best adds a security-through-obscurity aspect to hinder reverse engineering, at worst may introduce patterns that make your cyphertext easier to attack compared to simply increasing the key size used with a single well designed algorithm.</p><p>IANASR (I am not a security researcher)</p></div>
	</htmltext>
<tokenext>Even if it 's ASCII or a picture , just encrypt it twice.I 've always wondered what would happen if you were to encrypt a file over and over again , with different keys.You get Triple-DES [ wikipedia.org ] .Also , consider that encryption algorithms are not magic .
Having no distinguishable pattern to attacker is the goal , but the data is not actually random !
Encryption comes down to applying a set of mathematical transformations on your data which leaves " fingerprints " in the cyphertext if you know what to look for .
Applying more than one algorithm or the same algorithm more than once at best adds a security-through-obscurity aspect to hinder reverse engineering , at worst may introduce patterns that make your cyphertext easier to attack compared to simply increasing the key size used with a single well designed algorithm.IANASR ( I am not a security researcher )</tokentext>
<sentencetext>Even if it's ASCII or a picture, just encrypt it twice.I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.You get Triple-DES [wikipedia.org].Also, consider that encryption algorithms are not magic.
Having no distinguishable pattern to attacker is the goal, but the data is not actually random!
Encryption comes down to applying a set of mathematical transformations on your data which leaves "fingerprints" in the cyphertext if you know what to look for.
Applying more than one algorithm or the same algorithm more than once at best adds a security-through-obscurity aspect to hinder reverse engineering, at worst may introduce patterns that make your cyphertext easier to attack compared to simply increasing the key size used with a single well designed algorithm.IANASR (I am not a security researcher)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948646</id>
	<title>Defective by design</title>
	<author>Anonymous</author>
	<datestamp>1264776720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>DES was obsolete from the day it was invented.  Whose idea was it to use <a href="http://en.wikipedia.org/wiki/Data\_Encryption\_Standard" title="wikipedia.org" rel="nofollow">56 bits instead of 64?</a> [wikipedia.org]  Our friends at NSA, who pushed for 48 bits and settled for 56.  It seems that 56 bits was within THEIR capabilities back in the mid-70's but it wasn't so easy that anyone else was expected to do it.</p><p>My guess is that NSA has been able to rip through DES like a hot knife through butter, and they have been able to do it since the DES spec was published.</p></htmltext>
<tokenext>DES was obsolete from the day it was invented .
Whose idea was it to use 56 bits instead of 64 ?
[ wikipedia.org ] Our friends at NSA , who pushed for 48 bits and settled for 56 .
It seems that 56 bits was within THEIR capabilities back in the mid-70 's but it was n't so easy that anyone else was expected to do it.My guess is that NSA has been able to rip through DES like a hot knife through butter , and they have been able to do it since the DES spec was published .</tokentext>
<sentencetext>DES was obsolete from the day it was invented.
Whose idea was it to use 56 bits instead of 64?
[wikipedia.org]  Our friends at NSA, who pushed for 48 bits and settled for 56.
It seems that 56 bits was within THEIR capabilities back in the mid-70's but it wasn't so easy that anyone else was expected to do it.My guess is that NSA has been able to rip through DES like a hot knife through butter, and they have been able to do it since the DES spec was published.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948440</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30955766</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264762680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>Even if it's ASCII or a picture, just encrypt it twice.</p></div><p>I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.  Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted?  What would happen if you encrypted over and over using the same key?</p></div><p><div class="quote"><p><div class="quote"><p>Even if it's ASCII or a picture, just encrypt it twice.</p></div><p>I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.  Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted?  What would happen if you encrypted over and over using the same key?</p></div><p>That is where 3DES comes into picture. Encrypt-decrypt-encrypt effectively making the key length=3*56=158</p></div>
	</htmltext>
<tokenext>Even if it 's ASCII or a picture , just encrypt it twice.I 've always wondered what would happen if you were to encrypt a file over and over again , with different keys .
Would that lead to any greater security , or would somehow leave more and more obvious clues as to how the data was encrypted ?
What would happen if you encrypted over and over using the same key ? Even if it 's ASCII or a picture , just encrypt it twice.I 've always wondered what would happen if you were to encrypt a file over and over again , with different keys .
Would that lead to any greater security , or would somehow leave more and more obvious clues as to how the data was encrypted ?
What would happen if you encrypted over and over using the same key ? That is where 3DES comes into picture .
Encrypt-decrypt-encrypt effectively making the key length = 3 * 56 = 158</tokentext>
<sentencetext>Even if it's ASCII or a picture, just encrypt it twice.I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.
Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted?
What would happen if you encrypted over and over using the same key?Even if it's ASCII or a picture, just encrypt it twice.I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.
Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted?
What would happen if you encrypted over and over using the same key?That is where 3DES comes into picture.
Encrypt-decrypt-encrypt effectively making the key length=3*56=158
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952108</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Eil</author>
	<datestamp>1264790700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When brute-forcing a key, you have to have <i>some</i> idea of what the decrypted data looks like. If you're cracking a hard drive, for example, you'd check for a valid partition table. If you're cracking a text file, you'd check it for natural language words. An HTTPS packet probably has HTML tags somewhere inside, etc. In order to crack a packet of encrypted data, you need to know these things:</p><p>* The encryption algorithm<br>* The properties of its implementation (key length, any key derivation functions, the kind of padding used, etc)<br>* Context regarding the packet's purpose and origin (where it came from, what generated it, what it likely contains, etc)</p><p>And that's assuming that the encryption is weak enough to be cracked in the first place. (E.g., if it's AES-256, forget about it.) It would be a rather rare case that you had a chunk of data, knew exactly how it was encrypted, but didn't have any other context to go with it.</p></htmltext>
<tokenext>When brute-forcing a key , you have to have some idea of what the decrypted data looks like .
If you 're cracking a hard drive , for example , you 'd check for a valid partition table .
If you 're cracking a text file , you 'd check it for natural language words .
An HTTPS packet probably has HTML tags somewhere inside , etc .
In order to crack a packet of encrypted data , you need to know these things : * The encryption algorithm * The properties of its implementation ( key length , any key derivation functions , the kind of padding used , etc ) * Context regarding the packet 's purpose and origin ( where it came from , what generated it , what it likely contains , etc ) And that 's assuming that the encryption is weak enough to be cracked in the first place .
( E.g. , if it 's AES-256 , forget about it .
) It would be a rather rare case that you had a chunk of data , knew exactly how it was encrypted , but did n't have any other context to go with it .</tokentext>
<sentencetext>When brute-forcing a key, you have to have some idea of what the decrypted data looks like.
If you're cracking a hard drive, for example, you'd check for a valid partition table.
If you're cracking a text file, you'd check it for natural language words.
An HTTPS packet probably has HTML tags somewhere inside, etc.
In order to crack a packet of encrypted data, you need to know these things:* The encryption algorithm* The properties of its implementation (key length, any key derivation functions, the kind of padding used, etc)* Context regarding the packet's purpose and origin (where it came from, what generated it, what it likely contains, etc)And that's assuming that the encryption is weak enough to be cracked in the first place.
(E.g., if it's AES-256, forget about it.
) It would be a rather rare case that you had a chunk of data, knew exactly how it was encrypted, but didn't have any other context to go with it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948710</id>
	<title>Re:What?</title>
	<author>Colin Smith</author>
	<datestamp>1264777020000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>I mean, yes, his DES-cracking hardware is about 800x faster than a PC. Where's the "Crypto Breakthrough"?</p></div><p>He noticed the previous researcher's "sleep" statements.</p><p>
&nbsp;</p></div>
	</htmltext>
<tokenext>I mean , yes , his DES-cracking hardware is about 800x faster than a PC .
Where 's the " Crypto Breakthrough " ? He noticed the previous researcher 's " sleep " statements .
 </tokentext>
<sentencetext>I mean, yes, his DES-cracking hardware is about 800x faster than a PC.
Where's the "Crypto Breakthrough"?He noticed the previous researcher's "sleep" statements.
 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948440</id>
	<title>Interesting but not shocking</title>
	<author>Shrike82</author>
	<datestamp>1264775580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>DES is obselete anyway, though the way the decryption was carried out is fairly interesting. A little bit of homework shows that (apparently) a 56-bit DES key <a href="http://en.wikipedia.org/wiki/Data\_Encryption\_Standard" title="wikipedia.org">was broken in less than a day</a> [wikipedia.org] over ten years ago. So he's a decade late and 66\% less efficient!</htmltext>
<tokenext>DES is obselete anyway , though the way the decryption was carried out is fairly interesting .
A little bit of homework shows that ( apparently ) a 56-bit DES key was broken in less than a day [ wikipedia.org ] over ten years ago .
So he 's a decade late and 66 \ % less efficient !</tokentext>
<sentencetext>DES is obselete anyway, though the way the decryption was carried out is fairly interesting.
A little bit of homework shows that (apparently) a 56-bit DES key was broken in less than a day [wikipedia.org] over ten years ago.
So he's a decade late and 66\% less efficient!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950088</id>
	<title>Shhhhhhh</title>
	<author>scorp1us</author>
	<datestamp>1264783680000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext><p>Zip it. Ladies and gentlemen of the jury, ex-zip-it A. Look! I'm "Zippy" Longstocking! When a problem comes along, you must zip it!  Zip it good! Zip! Would you like to have a suckle of my "zipple"?</p></htmltext>
<tokenext>Zip it .
Ladies and gentlemen of the jury , ex-zip-it A. Look ! I 'm " Zippy " Longstocking !
When a problem comes along , you must zip it !
Zip it good !
Zip ! Would you like to have a suckle of my " zipple " ?</tokentext>
<sentencetext>Zip it.
Ladies and gentlemen of the jury, ex-zip-it A. Look! I'm "Zippy" Longstocking!
When a problem comes along, you must zip it!
Zip it good!
Zip! Would you like to have a suckle of my "zipple"?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30956650</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264766400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In certain contexts, 3DES is roughly equivalent to an hypotetical DES with a 112 bits keys. In the same context, double encryption only marginaly increase security.</p><p>See meet in the middle. This is probably applicable to any kind of multi encryptions.</p></htmltext>
<tokenext>In certain contexts , 3DES is roughly equivalent to an hypotetical DES with a 112 bits keys .
In the same context , double encryption only marginaly increase security.See meet in the middle .
This is probably applicable to any kind of multi encryptions .</tokentext>
<sentencetext>In certain contexts, 3DES is roughly equivalent to an hypotetical DES with a 112 bits keys.
In the same context, double encryption only marginaly increase security.See meet in the middle.
This is probably applicable to any kind of multi encryptions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948382</id>
	<title>I'm safe</title>
	<author>Anonymous</author>
	<datestamp>1264775160000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p>Moved to 57-bit DES years ago.</p></htmltext>
<tokenext>Moved to 57-bit DES years ago .</tokentext>
<sentencetext>Moved to 57-bit DES years ago.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264775760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Even if it's ASCII or a picture, just encrypt it twice.</htmltext>
<tokenext>Even if it 's ASCII or a picture , just encrypt it twice .</tokentext>
<sentencetext>Even if it's ASCII or a picture, just encrypt it twice.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949590</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264781640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>umm, no actually. Random data looks, well, random. When you suddenly have lots of organized and repeating data, it's pretty darn easy to spot. I've actually made the assessment several thousand times using wireshark. 1. Yep, that looks like its encrypted random crap. 2. Nope, that's nice and organized binary protocol exchanges. They're just automating it to "decrypt fixed-size blocks" locking for things that look like ASCII. Fairly simple concept, but someone actually has to take the time to build one.</p></htmltext>
<tokenext>umm , no actually .
Random data looks , well , random .
When you suddenly have lots of organized and repeating data , it 's pretty darn easy to spot .
I 've actually made the assessment several thousand times using wireshark .
1. Yep , that looks like its encrypted random crap .
2. Nope , that 's nice and organized binary protocol exchanges .
They 're just automating it to " decrypt fixed-size blocks " locking for things that look like ASCII .
Fairly simple concept , but someone actually has to take the time to build one .</tokentext>
<sentencetext>umm, no actually.
Random data looks, well, random.
When you suddenly have lots of organized and repeating data, it's pretty darn easy to spot.
I've actually made the assessment several thousand times using wireshark.
1. Yep, that looks like its encrypted random crap.
2. Nope, that's nice and organized binary protocol exchanges.
They're just automating it to "decrypt fixed-size blocks" locking for things that look like ASCII.
Fairly simple concept, but someone actually has to take the time to build one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948468</id>
	<title>Another win for Linux, the death of MS approaches</title>
	<author>Anonymous</author>
	<datestamp>1264775760000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Yet again Linux shows how superior open sourced software is in comparison to closed source, proprietary code like Windows. Were this algorithm to run under Windows, it would be slowed down so much by all the DRM checking the key-cracking code (assuming it would let that code run <b>at all</b>) that it probably wouldn't achieve a hundredth the throughput.</p><p>Not only that, but this being open source software, people can inspect the code and make it even faster. </p><p>Microsoft: your days are numbered.</p></htmltext>
<tokenext>Yet again Linux shows how superior open sourced software is in comparison to closed source , proprietary code like Windows .
Were this algorithm to run under Windows , it would be slowed down so much by all the DRM checking the key-cracking code ( assuming it would let that code run at all ) that it probably would n't achieve a hundredth the throughput.Not only that , but this being open source software , people can inspect the code and make it even faster .
Microsoft : your days are numbered .</tokentext>
<sentencetext>Yet again Linux shows how superior open sourced software is in comparison to closed source, proprietary code like Windows.
Were this algorithm to run under Windows, it would be slowed down so much by all the DRM checking the key-cracking code (assuming it would let that code run at all) that it probably wouldn't achieve a hundredth the throughput.Not only that, but this being open source software, people can inspect the code and make it even faster.
Microsoft: your days are numbered.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948408</id>
	<title>WTF????</title>
	<author>Anonymous</author>
	<datestamp>1264775340000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>Totally off-topic, but WTF is with the Facebook and Twitter links on all of the stories?  Who fucking cares?</p></htmltext>
<tokenext>Totally off-topic , but WTF is with the Facebook and Twitter links on all of the stories ?
Who fucking cares ?</tokentext>
<sentencetext>Totally off-topic, but WTF is with the Facebook and Twitter links on all of the stories?
Who fucking cares?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949606</id>
	<title>Re:Should be building standardised FPGAs into syst</title>
	<author>Hurricane78</author>
	<datestamp>1264781700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Isn&rsquo;t that, what Transmeta was all about?</p><p>I always wondered why it failed. It certainly wasn&rsquo;t because of the idea or because of me.</p></htmltext>
<tokenext>Isn    t that , what Transmeta was all about ? I always wondered why it failed .
It certainly wasn    t because of the idea or because of me .</tokentext>
<sentencetext>Isn’t that, what Transmeta was all about?I always wondered why it failed.
It certainly wasn’t because of the idea or because of me.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948360</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</id>
	<title>How do you know when it's decrypted?</title>
	<author>petes\_PoV</author>
	<datestamp>1264775160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext>Apart form the trivial case where some ASCII, or a picture pops up, how can a decrypter know when the block or stream of apparently random data has been decrypted?
<p>
If I was to start transmitting some random data and told people it was encrypted with DES 56 bit, but in fact it wasn't - it was just random data. Then, apart from exhaustively testing it with every possible key, how could they demonstrate that it was NOT encrypted as claimed?
<br>It does seem to me that one of the problems with decrypting "stuff" is that you need to have some idea what the "answer" will look like. Without that you can't ever be certain when you've succeeded.</p></htmltext>
<tokenext>Apart form the trivial case where some ASCII , or a picture pops up , how can a decrypter know when the block or stream of apparently random data has been decrypted ?
If I was to start transmitting some random data and told people it was encrypted with DES 56 bit , but in fact it was n't - it was just random data .
Then , apart from exhaustively testing it with every possible key , how could they demonstrate that it was NOT encrypted as claimed ?
It does seem to me that one of the problems with decrypting " stuff " is that you need to have some idea what the " answer " will look like .
Without that you ca n't ever be certain when you 've succeeded .</tokentext>
<sentencetext>Apart form the trivial case where some ASCII, or a picture pops up, how can a decrypter know when the block or stream of apparently random data has been decrypted?
If I was to start transmitting some random data and told people it was encrypted with DES 56 bit, but in fact it wasn't - it was just random data.
Then, apart from exhaustively testing it with every possible key, how could they demonstrate that it was NOT encrypted as claimed?
It does seem to me that one of the problems with decrypting "stuff" is that you need to have some idea what the "answer" will look like.
Without that you can't ever be certain when you've succeeded.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30953580</id>
	<title>Re:Practical value</title>
	<author>Anonymous</author>
	<datestamp>1264796820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Really? What polynomial does DES use?</p></htmltext>
<tokenext>Really ?
What polynomial does DES use ?</tokentext>
<sentencetext>Really?
What polynomial does DES use?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</id>
	<title>searching for ASCII</title>
	<author>roman\_mir</author>
	<datestamp>1264774860000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Finally, in your face, everyone who is not using binary to encode your messages and sticks to silly data-structures like XML with ASCII in it.</p></htmltext>
<tokenext>Finally , in your face , everyone who is not using binary to encode your messages and sticks to silly data-structures like XML with ASCII in it .</tokentext>
<sentencetext>Finally, in your face, everyone who is not using binary to encode your messages and sticks to silly data-structures like XML with ASCII in it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952214</id>
	<title>Re:Should be building standardised FPGAs into syst</title>
	<author>digitalunity</author>
	<datestamp>1264791000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Linus?</p></htmltext>
<tokenext>Linus ?</tokentext>
<sentencetext>Linus?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949606</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950110</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>tepples</author>
	<datestamp>1264783680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>it works better to just use a larger key</p></div><p>That's not always easy, especially if you have sunk a lot of money into crypto hardware that supports only short keys. That's one reason why triple DES took off: existing DES ASICs could still handle it.</p></div>
	</htmltext>
<tokenext>it works better to just use a larger keyThat 's not always easy , especially if you have sunk a lot of money into crypto hardware that supports only short keys .
That 's one reason why triple DES took off : existing DES ASICs could still handle it .</tokentext>
<sentencetext>it works better to just use a larger keyThat's not always easy, especially if you have sunk a lot of money into crypto hardware that supports only short keys.
That's one reason why triple DES took off: existing DES ASICs could still handle it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948860</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952438</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>pclminion</author>
	<datestamp>1264791840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Depends whether the cipher is "idempotent" or not. If a cipher is idempotent, then encrypting with key A followed by key B is the same as encrypting just a single time with some key C. Clearly, this is no more secure than just encrypting once, since you only need to find key C. If a cipher is NOT idempotent, the result of encrypting by A and then by B can't be reproduced by any single key C.</p></htmltext>
<tokenext>Depends whether the cipher is " idempotent " or not .
If a cipher is idempotent , then encrypting with key A followed by key B is the same as encrypting just a single time with some key C. Clearly , this is no more secure than just encrypting once , since you only need to find key C. If a cipher is NOT idempotent , the result of encrypting by A and then by B ca n't be reproduced by any single key C .</tokentext>
<sentencetext>Depends whether the cipher is "idempotent" or not.
If a cipher is idempotent, then encrypting with key A followed by key B is the same as encrypting just a single time with some key C. Clearly, this is no more secure than just encrypting once, since you only need to find key C. If a cipher is NOT idempotent, the result of encrypting by A and then by B can't be reproduced by any single key C.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951220</id>
	<title>Re:Defective by design</title>
	<author>keckbug</author>
	<datestamp>1264787760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>While I can't argue that NSA hasn't been able to decode DES from an early point, it's not all doom and gloom.

From the same Wikipedia page are several sources confirming that Lucifer, as initially conceived by IBM, was vulnerable to differential cryptanalysis, and the NSA's modifications, back in 1974, significantly strengthened the subsequent DES algorithm.  This wasn't confirmed until 1990.  Before we dismiss any government involvement out of hand, lets consider all sides.

Relevant passage from Wikipedia:

Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis, a general method for breaking block ciphers. The S-boxes of DES were much more resistant to the attack than if they had been chosen at random, strongly suggesting that IBM knew about the technique back in the 1970s. This was indeed the case &mdash; in 1994, Don Coppersmith published some of the original design criteria for the S-boxes. According to Steven Levy, IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and were asked by the NSA to keep the technique secret.</htmltext>
<tokenext>While I ca n't argue that NSA has n't been able to decode DES from an early point , it 's not all doom and gloom .
From the same Wikipedia page are several sources confirming that Lucifer , as initially conceived by IBM , was vulnerable to differential cryptanalysis , and the NSA 's modifications , back in 1974 , significantly strengthened the subsequent DES algorithm .
This was n't confirmed until 1990 .
Before we dismiss any government involvement out of hand , lets consider all sides .
Relevant passage from Wikipedia : Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990 , with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis , a general method for breaking block ciphers .
The S-boxes of DES were much more resistant to the attack than if they had been chosen at random , strongly suggesting that IBM knew about the technique back in the 1970s .
This was indeed the case    in 1994 , Don Coppersmith published some of the original design criteria for the S-boxes .
According to Steven Levy , IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and were asked by the NSA to keep the technique secret .</tokentext>
<sentencetext>While I can't argue that NSA hasn't been able to decode DES from an early point, it's not all doom and gloom.
From the same Wikipedia page are several sources confirming that Lucifer, as initially conceived by IBM, was vulnerable to differential cryptanalysis, and the NSA's modifications, back in 1974, significantly strengthened the subsequent DES algorithm.
This wasn't confirmed until 1990.
Before we dismiss any government involvement out of hand, lets consider all sides.
Relevant passage from Wikipedia:

Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis, a general method for breaking block ciphers.
The S-boxes of DES were much more resistant to the attack than if they had been chosen at random, strongly suggesting that IBM knew about the technique back in the 1970s.
This was indeed the case — in 1994, Don Coppersmith published some of the original design criteria for the S-boxes.
According to Steven Levy, IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and were asked by the NSA to keep the technique secret.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948646</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30960394</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>DrJimbo</author>
	<datestamp>1264842420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>It does seem to me that one of the problems with decrypting "stuff" is that you need to have some idea what the "answer" will look like.</p></div><p>This is a very good point.  The book
<a href="http://www.amazon.com/Battle-Wits-Complete-Story-Codebreaking/dp/0743217349" title="amazon.com">
Battle of Wits: The Complete Story of Codebreaking in World War II</a> [amazon.com] explains in great detail how various Axis codes were broken by the Allies.   Knowing what the "answer" looked like was essential for much of the codebreaking.  In fact, Turing's masterful technique to use machines to automatically decrypt messages encrypted by the more advanced German Enigma machines relied on knowing <i>exactly</i> a portion of the plaintext of one of the messages.  Once one message was cracked this way they were usually able to rather quickly decrypt all the other messages that used the same key that day.
<br> <br>
Much of the WW-II vintage decryption was based on exploiting patterns in the plaintext (such as letter or word frequency) that left a trace in the encrypted messages.  It is amazing how extremely subtle patterns were detected and then exploited.  IMO, most of WW-II codebreaking was based on these subtle patterns.  The other part of the codebreaking involved stealing the keys (codebooks, etc.) from the enemy.
<br> <br>
As you suggest, if there is no pattern in the plaintext then breaking the encryption is much harder and often impossible.</p></div>
	</htmltext>
<tokenext>It does seem to me that one of the problems with decrypting " stuff " is that you need to have some idea what the " answer " will look like.This is a very good point .
The book Battle of Wits : The Complete Story of Codebreaking in World War II [ amazon.com ] explains in great detail how various Axis codes were broken by the Allies .
Knowing what the " answer " looked like was essential for much of the codebreaking .
In fact , Turing 's masterful technique to use machines to automatically decrypt messages encrypted by the more advanced German Enigma machines relied on knowing exactly a portion of the plaintext of one of the messages .
Once one message was cracked this way they were usually able to rather quickly decrypt all the other messages that used the same key that day .
Much of the WW-II vintage decryption was based on exploiting patterns in the plaintext ( such as letter or word frequency ) that left a trace in the encrypted messages .
It is amazing how extremely subtle patterns were detected and then exploited .
IMO , most of WW-II codebreaking was based on these subtle patterns .
The other part of the codebreaking involved stealing the keys ( codebooks , etc .
) from the enemy .
As you suggest , if there is no pattern in the plaintext then breaking the encryption is much harder and often impossible .</tokentext>
<sentencetext>It does seem to me that one of the problems with decrypting "stuff" is that you need to have some idea what the "answer" will look like.This is a very good point.
The book

Battle of Wits: The Complete Story of Codebreaking in World War II [amazon.com] explains in great detail how various Axis codes were broken by the Allies.
Knowing what the "answer" looked like was essential for much of the codebreaking.
In fact, Turing's masterful technique to use machines to automatically decrypt messages encrypted by the more advanced German Enigma machines relied on knowing exactly a portion of the plaintext of one of the messages.
Once one message was cracked this way they were usually able to rather quickly decrypt all the other messages that used the same key that day.
Much of the WW-II vintage decryption was based on exploiting patterns in the plaintext (such as letter or word frequency) that left a trace in the encrypted messages.
It is amazing how extremely subtle patterns were detected and then exploited.
IMO, most of WW-II codebreaking was based on these subtle patterns.
The other part of the codebreaking involved stealing the keys (codebooks, etc.
) from the enemy.
As you suggest, if there is no pattern in the plaintext then breaking the encryption is much harder and often impossible.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948848</id>
	<title>Re:Should be building standardised FPGAs into syst</title>
	<author>Anonymous</author>
	<datestamp>1264777920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Yeah, well Xilinx pursued this in the early 90s with a swappable FPGA with an open architecture.  That was discontinued pretty quickly, though.</p><p>The main issue is that apps aren't slow in the right way.  Very few apps these days are in fact ALU-bound.  With GPU resources and SSE, even fewer need extra ALU power, and the hard limits come from memory access speed (especially random access, as required by a great many algorithms).  FPGAs don't really make this any easier (except insofar as they can offer *small* local caches which are blisteringly fast).</p><p>Also, any application domain which does have a speed problem tends to get hardware accelerator support pretty quickly - think of H.264 encoding, for instance.  Whatever can be done on an FPGA is already done in various other products.  None-the-less, a generic FPGA in every computer would reduce the need for all this custom silicon.</p><p>Personally I like the idea, but I fear it is too "niche" to ever make it as a standard PC component.</p><p>OTOH, what Intel etc. might consider is putting some FPGAable "special instructions" in the ISA, then attaching some FPGA resources that can be programmed in a relatively simple manner to execute some specially-needed instruction.  I used to dream of this back in the early 90s when I was writing texture-mapping software<nobr> <wbr></nobr>... the bit-twiddling there can take several instructions, whereas a few custom FPGA cells could do the same thing in one inst.  But then, the programmer would want to implement pipelining on anything &gt; 1 cycle, and that could be interesting to interface back to the main core.</p><p>For the niche applications where this all makes sense, you can buy some pretty awesome development kits.  Pico Computing (mentioned in TFA) look to make interesting products, but there is also the whole XGameStation thing which - thanks to its nature - can easily be repurposed.</p></htmltext>
<tokenext>Yeah , well Xilinx pursued this in the early 90s with a swappable FPGA with an open architecture .
That was discontinued pretty quickly , though.The main issue is that apps are n't slow in the right way .
Very few apps these days are in fact ALU-bound .
With GPU resources and SSE , even fewer need extra ALU power , and the hard limits come from memory access speed ( especially random access , as required by a great many algorithms ) .
FPGAs do n't really make this any easier ( except insofar as they can offer * small * local caches which are blisteringly fast ) .Also , any application domain which does have a speed problem tends to get hardware accelerator support pretty quickly - think of H.264 encoding , for instance .
Whatever can be done on an FPGA is already done in various other products .
None-the-less , a generic FPGA in every computer would reduce the need for all this custom silicon.Personally I like the idea , but I fear it is too " niche " to ever make it as a standard PC component.OTOH , what Intel etc .
might consider is putting some FPGAable " special instructions " in the ISA , then attaching some FPGA resources that can be programmed in a relatively simple manner to execute some specially-needed instruction .
I used to dream of this back in the early 90s when I was writing texture-mapping software ... the bit-twiddling there can take several instructions , whereas a few custom FPGA cells could do the same thing in one inst .
But then , the programmer would want to implement pipelining on anything &gt; 1 cycle , and that could be interesting to interface back to the main core.For the niche applications where this all makes sense , you can buy some pretty awesome development kits .
Pico Computing ( mentioned in TFA ) look to make interesting products , but there is also the whole XGameStation thing which - thanks to its nature - can easily be repurposed .</tokentext>
<sentencetext>Yeah, well Xilinx pursued this in the early 90s with a swappable FPGA with an open architecture.
That was discontinued pretty quickly, though.The main issue is that apps aren't slow in the right way.
Very few apps these days are in fact ALU-bound.
With GPU resources and SSE, even fewer need extra ALU power, and the hard limits come from memory access speed (especially random access, as required by a great many algorithms).
FPGAs don't really make this any easier (except insofar as they can offer *small* local caches which are blisteringly fast).Also, any application domain which does have a speed problem tends to get hardware accelerator support pretty quickly - think of H.264 encoding, for instance.
Whatever can be done on an FPGA is already done in various other products.
None-the-less, a generic FPGA in every computer would reduce the need for all this custom silicon.Personally I like the idea, but I fear it is too "niche" to ever make it as a standard PC component.OTOH, what Intel etc.
might consider is putting some FPGAable "special instructions" in the ISA, then attaching some FPGA resources that can be programmed in a relatively simple manner to execute some specially-needed instruction.
I used to dream of this back in the early 90s when I was writing texture-mapping software ... the bit-twiddling there can take several instructions, whereas a few custom FPGA cells could do the same thing in one inst.
But then, the programmer would want to implement pipelining on anything &gt; 1 cycle, and that could be interesting to interface back to the main core.For the niche applications where this all makes sense, you can buy some pretty awesome development kits.
Pico Computing (mentioned in TFA) look to make interesting products, but there is also the whole XGameStation thing which - thanks to its nature - can easily be repurposed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948360</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949266</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>TRS80NT</author>
	<datestamp>1264780200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A good question.  An analog from simpler times:<br>
More years ago than I care to count on my fingers I was a cryptanalyst in...let's say, near, the Mideast.  The traffic we were intercepting and working on was in Russian, Italian or one of several dialects of Arabic, none of which I speak, or more to the point, read.  But when you are applying decryption techniques you don't necessarily have to know what exactly what the message says to make progress, just what the plaintext should LOOK like.</htmltext>
<tokenext>A good question .
An analog from simpler times : More years ago than I care to count on my fingers I was a cryptanalyst in...let 's say , near , the Mideast .
The traffic we were intercepting and working on was in Russian , Italian or one of several dialects of Arabic , none of which I speak , or more to the point , read .
But when you are applying decryption techniques you do n't necessarily have to know what exactly what the message says to make progress , just what the plaintext should LOOK like .</tokentext>
<sentencetext>A good question.
An analog from simpler times:
More years ago than I care to count on my fingers I was a cryptanalyst in...let's say, near, the Mideast.
The traffic we were intercepting and working on was in Russian, Italian or one of several dialects of Arabic, none of which I speak, or more to the point, read.
But when you are applying decryption techniques you don't necessarily have to know what exactly what the message says to make progress, just what the plaintext should LOOK like.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948938</id>
	<title>Re:searching for ASCII</title>
	<author>Anonymous</author>
	<datestamp>1264778460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As far as I understand, it is searching for ASCII <b>password candidates</b>, not ASCII data.</p></htmltext>
<tokenext>As far as I understand , it is searching for ASCII password candidates , not ASCII data .</tokentext>
<sentencetext>As far as I understand, it is searching for ASCII password candidates, not ASCII data.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952216</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>Anonymous</author>
	<datestamp>1264791000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Basically right, but your comment on security of DES with 168-bit key is false:</p><p>Quoting Wikipedia:<br>http://en.wikipedia.org/wiki/Data\_Encryption\_Standard</p><p>It is known that the maximum cryptographic security of DES is limited to about 64 bits, even when independently choosing all round subkeys instead of deriving them from a key, which would otherwise permit a security of 768 bits.</p></htmltext>
<tokenext>Basically right , but your comment on security of DES with 168-bit key is false : Quoting Wikipedia : http : //en.wikipedia.org/wiki/Data \ _Encryption \ _StandardIt is known that the maximum cryptographic security of DES is limited to about 64 bits , even when independently choosing all round subkeys instead of deriving them from a key , which would otherwise permit a security of 768 bits .</tokentext>
<sentencetext>Basically right, but your comment on security of DES with 168-bit key is false:Quoting Wikipedia:http://en.wikipedia.org/wiki/Data\_Encryption\_StandardIt is known that the maximum cryptographic security of DES is limited to about 64 bits, even when independently choosing all round subkeys instead of deriving them from a key, which would otherwise permit a security of 768 bits.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450</id>
	<title>Practical value</title>
	<author>buruonbrails</author>
	<datestamp>1264775580000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext>DES algorithm is quite similar to AES and Blowfish. I wonder, if this method (with a few modifications) could be used to crack AES and Blowfish-encrypted messages? Besides, many people still use DES and Triple-DES.</htmltext>
<tokenext>DES algorithm is quite similar to AES and Blowfish .
I wonder , if this method ( with a few modifications ) could be used to crack AES and Blowfish-encrypted messages ?
Besides , many people still use DES and Triple-DES .</tokentext>
<sentencetext>DES algorithm is quite similar to AES and Blowfish.
I wonder, if this method (with a few modifications) could be used to crack AES and Blowfish-encrypted messages?
Besides, many people still use DES and Triple-DES.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948860</id>
	<title>Re:How do you know when it's decrypted?</title>
	<author>maxume</author>
	<datestamp>1264777980000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>If the encryption is properly implemented, the repeated cycles should not reveal any information, but it works better to just use a larger key (encrypting twice with 2 different 2 bit keys should be roughly equivalent to encrypting once with a 3 bit key, 4 different 2 bit keys would be equivalent to a 4 bit key and so on, so just going up to a much larger key is probably easier).</p></htmltext>
<tokenext>If the encryption is properly implemented , the repeated cycles should not reveal any information , but it works better to just use a larger key ( encrypting twice with 2 different 2 bit keys should be roughly equivalent to encrypting once with a 3 bit key , 4 different 2 bit keys would be equivalent to a 4 bit key and so on , so just going up to a much larger key is probably easier ) .</tokentext>
<sentencetext>If the encryption is properly implemented, the repeated cycles should not reveal any information, but it works better to just use a larger key (encrypting twice with 2 different 2 bit keys should be roughly equivalent to encrypting once with a 3 bit key, 4 different 2 bit keys would be equivalent to a 4 bit key and so on, so just going up to a much larger key is probably easier).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30960394
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952526
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951484
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949606
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948360
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948982
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949302
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948536
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949266
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948602
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950088
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951220
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948646
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948440
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30955766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950648
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949746
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949382
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948614
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949166
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948938
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30954072
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951998
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949168
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948626
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952216
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949958
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950110
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948860
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948468
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948616
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30953580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949110
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30956650
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_29_0343233_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948848
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948360
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948440
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948646
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951220
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948360
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949606
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948848
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948418
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950648
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950338
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948710
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948336
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949168
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950088
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949166
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948468
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948866
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948938
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948340
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948378
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948478
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948624
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948860
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30950110
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30955766
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948982
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952526
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949140
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952216
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30956650
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952438
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949266
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948616
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949110
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949746
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30960394
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949302
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951998
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948602
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948536
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949590
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30952108
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948626
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949582
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30954072
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948450
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30953580
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949958
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30951484
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948614
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30949382
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_29_0343233.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_29_0343233.30948408
</commentlist>
</conversation>
