<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_01_05_1734242</id>
	<title>Encryption Cracked On NIST-Certified Flash Drives</title>
	<author>timothy</author>
	<datestamp>1262716620000</datestamp>
	<htmltext>An anonymous reader writes <i>"USB Flash drives with hardware based AES 256-bit encryption manufactured by Kingston, SanDisk and Verbatim have <a href="http://www.h-online.com/security/news/item/NIST-certified-USB-Flash-drives-with-hardware-encryption-cracked-895308.html">reportedly been cracked by security firm SySS</a>. These drives are advertised to meet security standards suitable for use with sensitive US Government data (unclassified, of course) as emphasized by the <a href="http://en.wikipedia.org/wiki/FIPS\_140-2">FIPS 140-2</a> Level 2 certificate issued by the US National Institute of Standards and Technology (NIST). It looks likes the Windows-based password entry program always sends the same character string to the drive after performing various crypto operations."</i></htmltext>
<tokenext>An anonymous reader writes " USB Flash drives with hardware based AES 256-bit encryption manufactured by Kingston , SanDisk and Verbatim have reportedly been cracked by security firm SySS .
These drives are advertised to meet security standards suitable for use with sensitive US Government data ( unclassified , of course ) as emphasized by the FIPS 140-2 Level 2 certificate issued by the US National Institute of Standards and Technology ( NIST ) .
It looks likes the Windows-based password entry program always sends the same character string to the drive after performing various crypto operations .
"</tokentext>
<sentencetext>An anonymous reader writes "USB Flash drives with hardware based AES 256-bit encryption manufactured by Kingston, SanDisk and Verbatim have reportedly been cracked by security firm SySS.
These drives are advertised to meet security standards suitable for use with sensitive US Government data (unclassified, of course) as emphasized by the FIPS 140-2 Level 2 certificate issued by the US National Institute of Standards and Technology (NIST).
It looks likes the Windows-based password entry program always sends the same character string to the drive after performing various crypto operations.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660832</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>IronKey Dave</author>
	<datestamp>1262686800000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>You are incorrect.  FIPS validated products cannot use the password for key generation.  Instead, they must use a random number generator to create the AES key (eg 256-bit key).  They password is used to gain access to the key.  So a short password can be used, yet you still get 256 bit encryption.  As long as brute force password protection counter is also implemented in hardware and cannot be rolled back, you do not need very long passwords (eg. set a 3 try limit).  Also, you should encrypt the random AES key with a SHA-256 hash of the password, so that the key isn't stored in the clear anywhere.</htmltext>
<tokenext>You are incorrect .
FIPS validated products can not use the password for key generation .
Instead , they must use a random number generator to create the AES key ( eg 256-bit key ) .
They password is used to gain access to the key .
So a short password can be used , yet you still get 256 bit encryption .
As long as brute force password protection counter is also implemented in hardware and can not be rolled back , you do not need very long passwords ( eg .
set a 3 try limit ) .
Also , you should encrypt the random AES key with a SHA-256 hash of the password , so that the key is n't stored in the clear anywhere .</tokentext>
<sentencetext>You are incorrect.
FIPS validated products cannot use the password for key generation.
Instead, they must use a random number generator to create the AES key (eg 256-bit key).
They password is used to gain access to the key.
So a short password can be used, yet you still get 256 bit encryption.
As long as brute force password protection counter is also implemented in hardware and cannot be rolled back, you do not need very long passwords (eg.
set a 3 try limit).
Also, you should encrypt the random AES key with a SHA-256 hash of the password, so that the key isn't stored in the clear anywhere.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659872</id>
	<title>Re:Insider</title>
	<author>the\_pointman</author>
	<datestamp>1262683500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This has been very helpful. Thanks!</p></htmltext>
<tokenext>This has been very helpful .
Thanks !</tokentext>
<sentencetext>This has been very helpful.
Thanks!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659618</id>
	<title>Re:Not completely hardware based encryption then?</title>
	<author>DavidTC</author>
	<datestamp>1262682300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's the thing that gets me about USB hardware encryption. I can't figure out the damn point.</p><p>
The only possible advantage is that hardware encryption could maybe work without admin privs.</p></htmltext>
<tokenext>That 's the thing that gets me about USB hardware encryption .
I ca n't figure out the damn point .
The only possible advantage is that hardware encryption could maybe work without admin privs .</tokentext>
<sentencetext>That's the thing that gets me about USB hardware encryption.
I can't figure out the damn point.
The only possible advantage is that hardware encryption could maybe work without admin privs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30688752</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>mlts</author>
	<datestamp>1262864580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is why I like drives with proven security records like the IronKey, as well as smart cards.  The controller doesn't just want a key for decryption, it will stop bad password guesses by either adding a longer and longer delay time before a password request ir processed, or just overtly erase stored keys after someone guesses wrong.  Of course, I'm sure some well-heeled organization with an advanced chip fab can take a smart card apart to yank out a stored key, but an organization that rich likely will start with a rubber hose first (cue proper XKCD panel here.)</p><p>Instead of unlimited guesses, a proper security device limits the amount of brute force guesses to 3-20 or so before the curtain goes down.</p></htmltext>
<tokenext>This is why I like drives with proven security records like the IronKey , as well as smart cards .
The controller does n't just want a key for decryption , it will stop bad password guesses by either adding a longer and longer delay time before a password request ir processed , or just overtly erase stored keys after someone guesses wrong .
Of course , I 'm sure some well-heeled organization with an advanced chip fab can take a smart card apart to yank out a stored key , but an organization that rich likely will start with a rubber hose first ( cue proper XKCD panel here .
) Instead of unlimited guesses , a proper security device limits the amount of brute force guesses to 3-20 or so before the curtain goes down .</tokentext>
<sentencetext>This is why I like drives with proven security records like the IronKey, as well as smart cards.
The controller doesn't just want a key for decryption, it will stop bad password guesses by either adding a longer and longer delay time before a password request ir processed, or just overtly erase stored keys after someone guesses wrong.
Of course, I'm sure some well-heeled organization with an advanced chip fab can take a smart card apart to yank out a stored key, but an organization that rich likely will start with a rubber hose first (cue proper XKCD panel here.
)Instead of unlimited guesses, a proper security device limits the amount of brute force guesses to 3-20 or so before the curtain goes down.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</id>
	<title>How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262720460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Can anyone explain to me why the disk manufacturers chose to reinvent the wheel, instead of using Truecrypt? As far as I know, Truecrypt encryption hasn't been broken yet.</p></htmltext>
<tokenext>Can anyone explain to me why the disk manufacturers chose to reinvent the wheel , instead of using Truecrypt ?
As far as I know , Truecrypt encryption has n't been broken yet .</tokentext>
<sentencetext>Can anyone explain to me why the disk manufacturers chose to reinvent the wheel, instead of using Truecrypt?
As far as I know, Truecrypt encryption hasn't been broken yet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660426</id>
	<title>Re:Not completely hardware based encryption then?</title>
	<author>Anonymous</author>
	<datestamp>1262685240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>From TFA:</p><p><div class="quote"><p>The USB drives in question <strong>encrypt the stored data via the practically uncrackable AES 256-bit hardware encryption</strong> system. Therefore, the main point of attack for accessing the plain text data stored on the drive is the password entry mechanism. When analysing the relevant Windows program, the SySS security experts found a rather blatant flaw that has quite obviously slipped through testers' nets. During a successful authorisation procedure the program will, irrespective of the password, always send the same character string to the drive after performing various crypto operations &ndash; and this is the case for all USB Flash drives of this type.</p></div><p>The problem is, encryption isn't done with the user's password. The user's password only unlocks the generic key.<br>The exploit found out what the generic key is (and the fact that the key is the same for all USB drives of this type!!!) so they could tell the stick to unencrypt files on the encrypted partition without knowledge of the user's password.</p><p>Process seems to be this:<br>1) First time initialization, ask the user for a password, use this to encrypt the generic key<br>2) Any subsequent uses of the stick, prompt for the password, decrypt the generic key and use that to decrypt data</p><p>This would have been perfectly fine if they used a different generic key for each drive, but because ALL drives of this type use the same key (even across different manufacturers) it is a big issue.<br>Almost seems like they took pointers on encryption from the guys at the MPAA.</p></div>
	</htmltext>
<tokenext>From TFA : The USB drives in question encrypt the stored data via the practically uncrackable AES 256-bit hardware encryption system .
Therefore , the main point of attack for accessing the plain text data stored on the drive is the password entry mechanism .
When analysing the relevant Windows program , the SySS security experts found a rather blatant flaw that has quite obviously slipped through testers ' nets .
During a successful authorisation procedure the program will , irrespective of the password , always send the same character string to the drive after performing various crypto operations    and this is the case for all USB Flash drives of this type.The problem is , encryption is n't done with the user 's password .
The user 's password only unlocks the generic key.The exploit found out what the generic key is ( and the fact that the key is the same for all USB drives of this type ! ! !
) so they could tell the stick to unencrypt files on the encrypted partition without knowledge of the user 's password.Process seems to be this : 1 ) First time initialization , ask the user for a password , use this to encrypt the generic key2 ) Any subsequent uses of the stick , prompt for the password , decrypt the generic key and use that to decrypt dataThis would have been perfectly fine if they used a different generic key for each drive , but because ALL drives of this type use the same key ( even across different manufacturers ) it is a big issue.Almost seems like they took pointers on encryption from the guys at the MPAA .</tokentext>
<sentencetext>From TFA:The USB drives in question encrypt the stored data via the practically uncrackable AES 256-bit hardware encryption system.
Therefore, the main point of attack for accessing the plain text data stored on the drive is the password entry mechanism.
When analysing the relevant Windows program, the SySS security experts found a rather blatant flaw that has quite obviously slipped through testers' nets.
During a successful authorisation procedure the program will, irrespective of the password, always send the same character string to the drive after performing various crypto operations – and this is the case for all USB Flash drives of this type.The problem is, encryption isn't done with the user's password.
The user's password only unlocks the generic key.The exploit found out what the generic key is (and the fact that the key is the same for all USB drives of this type!!!
) so they could tell the stick to unencrypt files on the encrypted partition without knowledge of the user's password.Process seems to be this:1) First time initialization, ask the user for a password, use this to encrypt the generic key2) Any subsequent uses of the stick, prompt for the password, decrypt the generic key and use that to decrypt dataThis would have been perfectly fine if they used a different generic key for each drive, but because ALL drives of this type use the same key (even across different manufacturers) it is a big issue.Almost seems like they took pointers on encryption from the guys at the MPAA.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659792</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>sjames</author>
	<datestamp>1262683140000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>More to the point, what's the point of a super lock if you're going to tape the key to the door?</p></htmltext>
<tokenext>More to the point , what 's the point of a super lock if you 're going to tape the key to the door ?</tokentext>
<sentencetext>More to the point, what's the point of a super lock if you're going to tape the key to the door?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658768</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660272</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>clone53421</author>
	<datestamp>1262684760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Would it be practical to hash their password with SHA-256 and use that as the 256-bit key?</p><p>Of course, there&rsquo;s an obvious question: Is it easier to reverse a SHA-256 hash of a 64-bit password than it is to crack the encryption of 64-bit AES-encrypted data? harder? the same?</p><p>(Obviously a short password will <em>always</em> be poor from a security standpoint. However, short of making people use 256-bit passwords, you have to compromise somehow.)</p></htmltext>
<tokenext>Would it be practical to hash their password with SHA-256 and use that as the 256-bit key ? Of course , there    s an obvious question : Is it easier to reverse a SHA-256 hash of a 64-bit password than it is to crack the encryption of 64-bit AES-encrypted data ?
harder ? the same ?
( Obviously a short password will always be poor from a security standpoint .
However , short of making people use 256-bit passwords , you have to compromise somehow .
)</tokentext>
<sentencetext>Would it be practical to hash their password with SHA-256 and use that as the 256-bit key?Of course, there’s an obvious question: Is it easier to reverse a SHA-256 hash of a 64-bit password than it is to crack the encryption of 64-bit AES-encrypted data?
harder? the same?
(Obviously a short password will always be poor from a security standpoint.
However, short of making people use 256-bit passwords, you have to compromise somehow.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658566</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262720880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>young skywalker, you mustn't forget that people said the same of md5 when john the ripper came out!</p></htmltext>
<tokenext>young skywalker , you must n't forget that people said the same of md5 when john the ripper came out !</tokentext>
<sentencetext>young skywalker, you mustn't forget that people said the same of md5 when john the ripper came out!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659296</id>
	<title>Re:Always sends the same character string</title>
	<author>plover</author>
	<datestamp>1262724060000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>"12345"</p></div><p>That reminds me that I have to change the combination on my luggage.</p></div>
	</htmltext>
<tokenext>" 12345 " That reminds me that I have to change the combination on my luggage .</tokentext>
<sentencetext>"12345"That reminds me that I have to change the combination on my luggage.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828</id>
	<title>Hmm</title>
	<author>ShooterNeo</author>
	<datestamp>1262686740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>I wonder how good the security REALLY is on nuclear arms.  It's entirely possible that there are holes as glaring as this one in the internal equipment used to control the launch of nuclear missiles.</p><p>Course, it is the ultimate in obscurity.  No one is ever allowed to connect any kind of debugger or sniffer to the control systems in a missile silo.  The plans of the system are a secret, and as I understand it many of the computers in there are very old, running obscure OSes (or no OS, just an assembly code loop) that no one has ever heard of, made custom for the project.</p><p>The original designers knew, but those guys might have worked on the project in the 70s or 80s, and many of them are probably dead or retired now.</p><p>No one is allowed physical access to any of the equipment either, with a "2 man rule" for anyone doing maintenance.  I would suspect that the techs who work on the system aren't given detailed enough design documents to work out how it actually functions.</p><p>So, not sure if it's really a problem.  Can't come up with ideas for attacking a system if you don't even know what the system is.  Kind of like being told that someone is encrypting a message, but you don't know how they are going to do it, nor can intercept any of the communication.</p><p>Still, in a sci fi story I am working, a group of terrorists are able to get physical access to the equipment in a missile silo, and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment.</p></htmltext>
<tokenext>I wonder how good the security REALLY is on nuclear arms .
It 's entirely possible that there are holes as glaring as this one in the internal equipment used to control the launch of nuclear missiles.Course , it is the ultimate in obscurity .
No one is ever allowed to connect any kind of debugger or sniffer to the control systems in a missile silo .
The plans of the system are a secret , and as I understand it many of the computers in there are very old , running obscure OSes ( or no OS , just an assembly code loop ) that no one has ever heard of , made custom for the project.The original designers knew , but those guys might have worked on the project in the 70s or 80s , and many of them are probably dead or retired now.No one is allowed physical access to any of the equipment either , with a " 2 man rule " for anyone doing maintenance .
I would suspect that the techs who work on the system are n't given detailed enough design documents to work out how it actually functions.So , not sure if it 's really a problem .
Ca n't come up with ideas for attacking a system if you do n't even know what the system is .
Kind of like being told that someone is encrypting a message , but you do n't know how they are going to do it , nor can intercept any of the communication.Still , in a sci fi story I am working , a group of terrorists are able to get physical access to the equipment in a missile silo , and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment .</tokentext>
<sentencetext>I wonder how good the security REALLY is on nuclear arms.
It's entirely possible that there are holes as glaring as this one in the internal equipment used to control the launch of nuclear missiles.Course, it is the ultimate in obscurity.
No one is ever allowed to connect any kind of debugger or sniffer to the control systems in a missile silo.
The plans of the system are a secret, and as I understand it many of the computers in there are very old, running obscure OSes (or no OS, just an assembly code loop) that no one has ever heard of, made custom for the project.The original designers knew, but those guys might have worked on the project in the 70s or 80s, and many of them are probably dead or retired now.No one is allowed physical access to any of the equipment either, with a "2 man rule" for anyone doing maintenance.
I would suspect that the techs who work on the system aren't given detailed enough design documents to work out how it actually functions.So, not sure if it's really a problem.
Can't come up with ideas for attacking a system if you don't even know what the system is.
Kind of like being told that someone is encrypting a message, but you don't know how they are going to do it, nor can intercept any of the communication.Still, in a sci fi story I am working, a group of terrorists are able to get physical access to the equipment in a missile silo, and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662100</id>
	<title>Re:Insider</title>
	<author>dbrez8</author>
	<datestamp>1262692260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well if IronKey Dave is going to plug his wares, above, then why not..<br>
<br>
If you're interested in additional secure flash drive options check out Kanguru Solution's Defender Elite products. We use on-chip password matching and 256bit AES(CBC) hardware encryption. The drive can be remotely administered and deleted per my other post via our KRMC web-based administration console. Please don't let the Sandisk products give our industry a bad name<br>
<br>
<a href="http://shop.kanguru.com/index.php/flash-drives/secure-storage/kanguru-defender-elite" title="kanguru.com" rel="nofollow">http://shop.kanguru.com/index.php/flash-drives/secure-storage/kanguru-defender-elite</a> [kanguru.com]
<a href="http://shop.kanguru.com/index.php/krmc" title="kanguru.com" rel="nofollow">http://shop.kanguru.com/index.php/krmc</a> [kanguru.com]</htmltext>
<tokenext>Well if IronKey Dave is going to plug his wares , above , then why not. . If you 're interested in additional secure flash drive options check out Kanguru Solution 's Defender Elite products .
We use on-chip password matching and 256bit AES ( CBC ) hardware encryption .
The drive can be remotely administered and deleted per my other post via our KRMC web-based administration console .
Please do n't let the Sandisk products give our industry a bad name http : //shop.kanguru.com/index.php/flash-drives/secure-storage/kanguru-defender-elite [ kanguru.com ] http : //shop.kanguru.com/index.php/krmc [ kanguru.com ]</tokentext>
<sentencetext>Well if IronKey Dave is going to plug his wares, above, then why not..

If you're interested in additional secure flash drive options check out Kanguru Solution's Defender Elite products.
We use on-chip password matching and 256bit AES(CBC) hardware encryption.
The drive can be remotely administered and deleted per my other post via our KRMC web-based administration console.
Please don't let the Sandisk products give our industry a bad name

http://shop.kanguru.com/index.php/flash-drives/secure-storage/kanguru-defender-elite [kanguru.com]
http://shop.kanguru.com/index.php/krmc [kanguru.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658772</id>
	<title>Re:Article title misleading...</title>
	<author>Anonymous</author>
	<datestamp>1262721540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If I RTFA correctly, the real problem is that all of these USB drives have the same encryption key. The Windows program that unlocks it is irrelevant. You could write your own program to send the fixed key directly to the USB drive, but apparently the researchers found it easier to ride on top of the existing program.</p><p>This reminds me of a web application that went through a sound password authentication system only to then "unlock" all the pages by appending "&amp;AUTH=T" to all the query strings.</p></htmltext>
<tokenext>If I RTFA correctly , the real problem is that all of these USB drives have the same encryption key .
The Windows program that unlocks it is irrelevant .
You could write your own program to send the fixed key directly to the USB drive , but apparently the researchers found it easier to ride on top of the existing program.This reminds me of a web application that went through a sound password authentication system only to then " unlock " all the pages by appending " &amp;AUTH = T " to all the query strings .</tokentext>
<sentencetext>If I RTFA correctly, the real problem is that all of these USB drives have the same encryption key.
The Windows program that unlocks it is irrelevant.
You could write your own program to send the fixed key directly to the USB drive, but apparently the researchers found it easier to ride on top of the existing program.This reminds me of a web application that went through a sound password authentication system only to then "unlock" all the pages by appending "&amp;AUTH=T" to all the query strings.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658972</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>tgd</author>
	<datestamp>1262722620000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>If you don't trust the host computer, why would you unlock the device at all?</p><p>Once its unlocked and mounted, anything on the computer can access it anyway.</p></htmltext>
<tokenext>If you do n't trust the host computer , why would you unlock the device at all ? Once its unlocked and mounted , anything on the computer can access it anyway .</tokentext>
<sentencetext>If you don't trust the host computer, why would you unlock the device at all?Once its unlocked and mounted, anything on the computer can access it anyway.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659344</id>
	<title>Re:Truecrypt</title>
	<author>interval1066</author>
	<datestamp>1262724300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yeah, that's my understanding as well. Its not an issue with Windows, per se. I would use TrueCrypt as well. (Which I do.)</htmltext>
<tokenext>Yeah , that 's my understanding as well .
Its not an issue with Windows , per se .
I would use TrueCrypt as well .
( Which I do .
)</tokentext>
<sentencetext>Yeah, that's my understanding as well.
Its not an issue with Windows, per se.
I would use TrueCrypt as well.
(Which I do.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458</id>
	<title>Truecrypt</title>
	<author>Anonymous</author>
	<datestamp>1262720460000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>0</modscore>
	<htmltext><p>Does this affect Truecrypt using the same encryption mode?</p></htmltext>
<tokenext>Does this affect Truecrypt using the same encryption mode ?</tokentext>
<sentencetext>Does this affect Truecrypt using the same encryption mode?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662866</id>
	<title>Ironkey ftw!</title>
	<author>Anonymous</author>
	<datestamp>1262696040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You get what you pay for... this is why I went with an IronKey!</p></htmltext>
<tokenext>You get what you pay for... this is why I went with an IronKey !</tokentext>
<sentencetext>You get what you pay for... this is why I went with an IronKey!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665788</id>
	<title>Re:IronKey?</title>
	<author>Jon Abbott</author>
	<datestamp>1262714640000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Thanks for posting this update.  I've always had respect for IronKey and that level of respect just went up a few notches.</p></htmltext>
<tokenext>Thanks for posting this update .
I 've always had respect for IronKey and that level of respect just went up a few notches .</tokentext>
<sentencetext>Thanks for posting this update.
I've always had respect for IronKey and that level of respect just went up a few notches.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660360</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658768</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262721480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>The info isn't encrypted, it's just locked with a password.</p></div></blockquote><p>Yeah, that's what the story seems to say.  But that makes no sense... Why have an AES 256-bit hardware encryption system if you're going to store the data unencrypted?  I mean.. it's all just bits as far as the memory chips are concerned.</p></div>
	</htmltext>
<tokenext>The info is n't encrypted , it 's just locked with a password.Yeah , that 's what the story seems to say .
But that makes no sense... Why have an AES 256-bit hardware encryption system if you 're going to store the data unencrypted ?
I mean.. it 's all just bits as far as the memory chips are concerned .</tokentext>
<sentencetext>The info isn't encrypted, it's just locked with a password.Yeah, that's what the story seems to say.
But that makes no sense... Why have an AES 256-bit hardware encryption system if you're going to store the data unencrypted?
I mean.. it's all just bits as far as the memory chips are concerned.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658532</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660924</id>
	<title>Re:It's not just the algorithm</title>
	<author>Anonymous</author>
	<datestamp>1262687160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Algorithms and security protocols are very often broken - however it takes sometimes decades to find their weaknesses.</p></htmltext>
<tokenext>Algorithms and security protocols are very often broken - however it takes sometimes decades to find their weaknesses .</tokentext>
<sentencetext>Algorithms and security protocols are very often broken - however it takes sometimes decades to find their weaknesses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659020</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658918</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>lhunath</author>
	<datestamp>1262722320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Exactly why they are putting fingerprint readers on these devices now (more usable way of entering a passphrase than a tiny PIN-pad on a tiny thumbdrive).</p><p>Also the reason why you should be getting a smartcard reader with a PIN-pad on it instead of a smartcard reader that relies on "drivers" asking you for a pin code on your computer.</p></htmltext>
<tokenext>Exactly why they are putting fingerprint readers on these devices now ( more usable way of entering a passphrase than a tiny PIN-pad on a tiny thumbdrive ) .Also the reason why you should be getting a smartcard reader with a PIN-pad on it instead of a smartcard reader that relies on " drivers " asking you for a pin code on your computer .</tokentext>
<sentencetext>Exactly why they are putting fingerprint readers on these devices now (more usable way of entering a passphrase than a tiny PIN-pad on a tiny thumbdrive).Also the reason why you should be getting a smartcard reader with a PIN-pad on it instead of a smartcard reader that relies on "drivers" asking you for a pin code on your computer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658718</id>
	<title>Re:IronKey?</title>
	<author>RemyBR</author>
	<datestamp>1262721360000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>The Ironkey should not be affected. It uses a different approach: first of all, the data on the drive is really encrypted, the drive is not only "locked" with a password. Secondly and most important, there's no validation of the password happening outside the drive (i.e. on a windows/linux/mac application). The application only lets you input your password, which is then validated by the drive itself via a ROM routine.</htmltext>
<tokenext>The Ironkey should not be affected .
It uses a different approach : first of all , the data on the drive is really encrypted , the drive is not only " locked " with a password .
Secondly and most important , there 's no validation of the password happening outside the drive ( i.e .
on a windows/linux/mac application ) .
The application only lets you input your password , which is then validated by the drive itself via a ROM routine .</tokentext>
<sentencetext>The Ironkey should not be affected.
It uses a different approach: first of all, the data on the drive is really encrypted, the drive is not only "locked" with a password.
Secondly and most important, there's no validation of the password happening outside the drive (i.e.
on a windows/linux/mac application).
The application only lets you input your password, which is then validated by the drive itself via a ROM routine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744</id>
	<title>Shouldn't trust the host computer AT ALL</title>
	<author>georgewilliamherbert</author>
	<datestamp>1262721420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>I don't believe why any portable secure drive needs to or should trust its host computer.  This is a particularly stupid implementation, with an obvious and blatant exploit.  But the host computer could by definition be compromised, and could intercept or store / cache or misbehave generically with the password you enter to get in.</p><p>Put a thumb-key sized numeric or hex keypad on the device, and make the owner punch in the code on insertion into a host device.  One could still physically break into and tap the keys somehow, if the device is stolen and then returned without the owner knowing, but the user interface moves to right next to the data...</p></htmltext>
<tokenext>I do n't believe why any portable secure drive needs to or should trust its host computer .
This is a particularly stupid implementation , with an obvious and blatant exploit .
But the host computer could by definition be compromised , and could intercept or store / cache or misbehave generically with the password you enter to get in.Put a thumb-key sized numeric or hex keypad on the device , and make the owner punch in the code on insertion into a host device .
One could still physically break into and tap the keys somehow , if the device is stolen and then returned without the owner knowing , but the user interface moves to right next to the data.. .</tokentext>
<sentencetext>I don't believe why any portable secure drive needs to or should trust its host computer.
This is a particularly stupid implementation, with an obvious and blatant exploit.
But the host computer could by definition be compromised, and could intercept or store / cache or misbehave generically with the password you enter to get in.Put a thumb-key sized numeric or hex keypad on the device, and make the owner punch in the code on insertion into a host device.
One could still physically break into and tap the keys somehow, if the device is stolen and then returned without the owner knowing, but the user interface moves to right next to the data...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659722</id>
	<title>Re:Always sends the same character string</title>
	<author>narcc</author>
	<datestamp>1262682780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've got the same combination on my luggage!</p></htmltext>
<tokenext>I 've got the same combination on my luggage !</tokentext>
<sentencetext>I've got the same combination on my luggage!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658830</id>
	<title>Re:IronKey?</title>
	<author>Andy Dodd</author>
	<datestamp>1262721780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I  would expect that the same thing that makes it cross-platform (drive handles authentication and unlocking, not the software) would make this particular attack (some dumbass offloaded authentication to the software) irrelevant.</p></htmltext>
<tokenext>I would expect that the same thing that makes it cross-platform ( drive handles authentication and unlocking , not the software ) would make this particular attack ( some dumbass offloaded authentication to the software ) irrelevant .</tokentext>
<sentencetext>I  would expect that the same thing that makes it cross-platform (drive handles authentication and unlocking, not the software) would make this particular attack (some dumbass offloaded authentication to the software) irrelevant.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660360</id>
	<title>Re:IronKey?</title>
	<author>Anonymous</author>
	<datestamp>1262685060000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>IronKey D200 and S200 models are validated to the much more demanding FIPS 140-2 Level 3.  The products that are the subject of this hack are validated to Level 2.  They are all in fact manufactured by SanDisk.

Previous authors are correct, their architecture has serious design flaws.  They are relying on the host PC to do password verification, and essentially using a static code to tell the device to unlock.  Basically it's a back door to all of those affected SanDisk, Kingston and Verbatim devices.

I will be posting an FAQ later today on the <a href="https://www.ironkey.com/" title="ironkey.com" rel="nofollow">https://www.ironkey.com/</a> [ironkey.com] website describing the flaws and how IronKey's architecture does not have these issues.

IronKey validates all passwords in hardware.  We have password replay prevention and encrypted USB command channels.  We also use a hash of the password to decrypt the data AES key, so it's cryptographically impossible to unlock an IronKey without the password.   Finally, IronKeys store encryption keys and brute force counters in a hardened CryptoChip.  The SanDisk, Kingston and Verbatim products store them in Flash memory, which isn't even part of their FIPS 140-2 security policy.

Dave</htmltext>
<tokenext>IronKey D200 and S200 models are validated to the much more demanding FIPS 140-2 Level 3 .
The products that are the subject of this hack are validated to Level 2 .
They are all in fact manufactured by SanDisk .
Previous authors are correct , their architecture has serious design flaws .
They are relying on the host PC to do password verification , and essentially using a static code to tell the device to unlock .
Basically it 's a back door to all of those affected SanDisk , Kingston and Verbatim devices .
I will be posting an FAQ later today on the https : //www.ironkey.com/ [ ironkey.com ] website describing the flaws and how IronKey 's architecture does not have these issues .
IronKey validates all passwords in hardware .
We have password replay prevention and encrypted USB command channels .
We also use a hash of the password to decrypt the data AES key , so it 's cryptographically impossible to unlock an IronKey without the password .
Finally , IronKeys store encryption keys and brute force counters in a hardened CryptoChip .
The SanDisk , Kingston and Verbatim products store them in Flash memory , which is n't even part of their FIPS 140-2 security policy .
Dave</tokentext>
<sentencetext>IronKey D200 and S200 models are validated to the much more demanding FIPS 140-2 Level 3.
The products that are the subject of this hack are validated to Level 2.
They are all in fact manufactured by SanDisk.
Previous authors are correct, their architecture has serious design flaws.
They are relying on the host PC to do password verification, and essentially using a static code to tell the device to unlock.
Basically it's a back door to all of those affected SanDisk, Kingston and Verbatim devices.
I will be posting an FAQ later today on the https://www.ironkey.com/ [ironkey.com] website describing the flaws and how IronKey's architecture does not have these issues.
IronKey validates all passwords in hardware.
We have password replay prevention and encrypted USB command channels.
We also use a hash of the password to decrypt the data AES key, so it's cryptographically impossible to unlock an IronKey without the password.
Finally, IronKeys store encryption keys and brute force counters in a hardened CryptoChip.
The SanDisk, Kingston and Verbatim products store them in Flash memory, which isn't even part of their FIPS 140-2 security policy.
Dave</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659122</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>gad\_zuki!</author>
	<datestamp>1262723340000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Portable Truecrypt has problems. The user will import their private key or at least have it somewhere they can get to it or use conventional cryptography. So there's a lot of security vulnerabilities right there. Oh, forgot to delete your private key? Now Im cracking the conventional encryption that protects it. TrueCrypt portable requierd admin privs:</p><blockquote><div><p>Also note that, as regards personal privacy, in most cases, it is not safe to work with sensitive data under systems where you do not have administrator privileges, because the administrator can easily capture and copy the sensitive data, including the passwords and keys.</p><p>However, users without administrator privileges cannot encrypt/format partitions, cannot create NTFS volumes, cannot install/uninstall TrueCrypt, cannot change passwords/keyfiles for TrueCrypt partitions/devices, cannot backup/restore headers of TrueCrypt partitions/devices, and they cannot run TrueCrypt in portable mode.</p></div></blockquote><p>The idea with these drives is that the app can be run from the drive itself, so no extra software or training is needed.  No key management. So that really just leaves us conventional cryptography, not public/private key.  The problem of having security on your USB drive that gets plugged into various computers that you might not have control over and may be running trojans is tough to solve.  Application level encryption is probably the best way to go but it requires standard installs and trust of the host computer.</p><p>Youre better off just carrying a netbook or other trusted security device with an encrypted drive and sharing the files via conventional methods with the host without giving the host all your data - email, ftp, web, plaintext transfers, etc.</p></div>
	</htmltext>
<tokenext>Portable Truecrypt has problems .
The user will import their private key or at least have it somewhere they can get to it or use conventional cryptography .
So there 's a lot of security vulnerabilities right there .
Oh , forgot to delete your private key ?
Now Im cracking the conventional encryption that protects it .
TrueCrypt portable requierd admin privs : Also note that , as regards personal privacy , in most cases , it is not safe to work with sensitive data under systems where you do not have administrator privileges , because the administrator can easily capture and copy the sensitive data , including the passwords and keys.However , users without administrator privileges can not encrypt/format partitions , can not create NTFS volumes , can not install/uninstall TrueCrypt , can not change passwords/keyfiles for TrueCrypt partitions/devices , can not backup/restore headers of TrueCrypt partitions/devices , and they can not run TrueCrypt in portable mode.The idea with these drives is that the app can be run from the drive itself , so no extra software or training is needed .
No key management .
So that really just leaves us conventional cryptography , not public/private key .
The problem of having security on your USB drive that gets plugged into various computers that you might not have control over and may be running trojans is tough to solve .
Application level encryption is probably the best way to go but it requires standard installs and trust of the host computer.Youre better off just carrying a netbook or other trusted security device with an encrypted drive and sharing the files via conventional methods with the host without giving the host all your data - email , ftp , web , plaintext transfers , etc .</tokentext>
<sentencetext>Portable Truecrypt has problems.
The user will import their private key or at least have it somewhere they can get to it or use conventional cryptography.
So there's a lot of security vulnerabilities right there.
Oh, forgot to delete your private key?
Now Im cracking the conventional encryption that protects it.
TrueCrypt portable requierd admin privs:Also note that, as regards personal privacy, in most cases, it is not safe to work with sensitive data under systems where you do not have administrator privileges, because the administrator can easily capture and copy the sensitive data, including the passwords and keys.However, users without administrator privileges cannot encrypt/format partitions, cannot create NTFS volumes, cannot install/uninstall TrueCrypt, cannot change passwords/keyfiles for TrueCrypt partitions/devices, cannot backup/restore headers of TrueCrypt partitions/devices, and they cannot run TrueCrypt in portable mode.The idea with these drives is that the app can be run from the drive itself, so no extra software or training is needed.
No key management.
So that really just leaves us conventional cryptography, not public/private key.
The problem of having security on your USB drive that gets plugged into various computers that you might not have control over and may be running trojans is tough to solve.
Application level encryption is probably the best way to go but it requires standard installs and trust of the host computer.Youre better off just carrying a netbook or other trusted security device with an encrypted drive and sharing the files via conventional methods with the host without giving the host all your data - email, ftp, web, plaintext transfers, etc.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658418</id>
	<title>Aye</title>
	<author>Anonymous</author>
	<datestamp>1262720340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Flash post!</p><p>R</p></htmltext>
<tokenext>Flash post ! R</tokentext>
<sentencetext>Flash post!R</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658532</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>jimbobborg</author>
	<datestamp>1262720760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>These aren't disks, they're USB thumb drives.  The folks who "cracked" it just figured out a way to bypass the password and send a specific string that ALL of these devices use to access the data on these USB thumb drives.  This seems to be endemic to these things.  The info isn't encrypted, it's just locked with a password.</p></htmltext>
<tokenext>These are n't disks , they 're USB thumb drives .
The folks who " cracked " it just figured out a way to bypass the password and send a specific string that ALL of these devices use to access the data on these USB thumb drives .
This seems to be endemic to these things .
The info is n't encrypted , it 's just locked with a password .</tokentext>
<sentencetext>These aren't disks, they're USB thumb drives.
The folks who "cracked" it just figured out a way to bypass the password and send a specific string that ALL of these devices use to access the data on these USB thumb drives.
This seems to be endemic to these things.
The info isn't encrypted, it's just locked with a password.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662612</id>
	<title>Re:Insider</title>
	<author>PhunkySchtuff</author>
	<datestamp>1262694960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Modern encryption algorithms all share a design goal of being fast to implement in hardware. Using a dedicated crypto chip to decrypt data can easily be faster than using a general purpose CPU to do it, particularly if the CPU is performing other tasks at the same time.</p><p>Either way, this argument is pretty much moot as the speed of decryption in these drives is probably bandwidth limited by the flash controller read speed anyway...</p></htmltext>
<tokenext>Modern encryption algorithms all share a design goal of being fast to implement in hardware .
Using a dedicated crypto chip to decrypt data can easily be faster than using a general purpose CPU to do it , particularly if the CPU is performing other tasks at the same time.Either way , this argument is pretty much moot as the speed of decryption in these drives is probably bandwidth limited by the flash controller read speed anyway.. .</tokentext>
<sentencetext>Modern encryption algorithms all share a design goal of being fast to implement in hardware.
Using a dedicated crypto chip to decrypt data can easily be faster than using a general purpose CPU to do it, particularly if the CPU is performing other tasks at the same time.Either way, this argument is pretty much moot as the speed of decryption in these drives is probably bandwidth limited by the flash controller read speed anyway...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660440</id>
	<title>So this is a USB tumb drive?</title>
	<author>Anonymous</author>
	<datestamp>1262685300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Do we get a new USB device profile reserved for such tumb drives?</p></htmltext>
<tokenext>Do we get a new USB device profile reserved for such tumb drives ?</tokentext>
<sentencetext>Do we get a new USB device profile reserved for such tumb drives?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30678124</id>
	<title>Re:Insider</title>
	<author>zippthorne</author>
	<datestamp>1262790960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Not to say HW encryption isn't a good idea from a security standpoint.</p></div><p>It isn't.  A device plugged into a laptop usb port probably isn't a problem, but having the decrypt on the drive instead of the cpu means that many more inches where the data is being transmitted in the clear.</p><p>The cpu would have access to the data anyway, to do whatever it needed to do with it, but why pass plaintext through more hands than it needs to?</p><p>Better yet, put the hardware crypto on the CPU die, so that the plaintext doesn't even exist in ram.</p></div>
	</htmltext>
<tokenext>Not to say HW encryption is n't a good idea from a security standpoint.It is n't .
A device plugged into a laptop usb port probably is n't a problem , but having the decrypt on the drive instead of the cpu means that many more inches where the data is being transmitted in the clear.The cpu would have access to the data anyway , to do whatever it needed to do with it , but why pass plaintext through more hands than it needs to ? Better yet , put the hardware crypto on the CPU die , so that the plaintext does n't even exist in ram .</tokentext>
<sentencetext>Not to say HW encryption isn't a good idea from a security standpoint.It isn't.
A device plugged into a laptop usb port probably isn't a problem, but having the decrypt on the drive instead of the cpu means that many more inches where the data is being transmitted in the clear.The cpu would have access to the data anyway, to do whatever it needed to do with it, but why pass plaintext through more hands than it needs to?Better yet, put the hardware crypto on the CPU die, so that the plaintext doesn't even exist in ram.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30663506</id>
	<title>Re:It's not just the algorithm NIKE JORDAN SHOES</title>
	<author>PUGH1986</author>
	<datestamp>1262698920000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><a href="http://www.allbyer.com/" title="allbyer.com" rel="nofollow">http://www.allbyer.com/</a> [allbyer.com]   Hi,Dear Ladies and Gentlemen,2010 New Year's gift you ready?Here are the most popular, most stylish and avantgarde shoes,handbags,Tshirts,jacket,Tracksuitw ect...NIKE SHOX,JORDAN SHOES 1-24,AF,DUNK,SB,PUMA<nobr> <wbr></nobr>,R4,NZ,OZ,T1-TL3) $35HANDBGAS(COACH,L V, DG, ED HARDY) $35TSHIRTS (POLO<nobr> <wbr></nobr>,ED HARDY, LACOSTE) $16 thanks... Company launched New Year carnival as long as the purchase of up to 200, both exquisite gift, surprise here, do not miss, welcome friends from all circles to come to order..,For details, please consult <a href="http://www.allbyer.com/" title="allbyer.com" rel="nofollow">http://www.allbyer.com/</a> [allbyer.com]</htmltext>
<tokenext>http : //www.allbyer.com/ [ allbyer.com ] Hi,Dear Ladies and Gentlemen,2010 New Year 's gift you ready ? Here are the most popular , most stylish and avantgarde shoes,handbags,Tshirts,jacket,Tracksuitw ect...NIKE SHOX,JORDAN SHOES 1-24,AF,DUNK,SB,PUMA ,R4,NZ,OZ,T1-TL3 ) $ 35HANDBGAS ( COACH,L V , DG , ED HARDY ) $ 35TSHIRTS ( POLO ,ED HARDY , LACOSTE ) $ 16 thanks... Company launched New Year carnival as long as the purchase of up to 200 , both exquisite gift , surprise here , do not miss , welcome friends from all circles to come to order..,For details , please consult http : //www.allbyer.com/ [ allbyer.com ]</tokentext>
<sentencetext>http://www.allbyer.com/ [allbyer.com]   Hi,Dear Ladies and Gentlemen,2010 New Year's gift you ready?Here are the most popular, most stylish and avantgarde shoes,handbags,Tshirts,jacket,Tracksuitw ect...NIKE SHOX,JORDAN SHOES 1-24,AF,DUNK,SB,PUMA ,R4,NZ,OZ,T1-TL3) $35HANDBGAS(COACH,L V, DG, ED HARDY) $35TSHIRTS (POLO ,ED HARDY, LACOSTE) $16 thanks... Company launched New Year carnival as long as the purchase of up to 200, both exquisite gift, surprise here, do not miss, welcome friends from all circles to come to order..,For details, please consult http://www.allbyer.com/ [allbyer.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662798</id>
	<title>Re:It's not just the algorithm</title>
	<author>clodney</author>
	<datestamp>1262695800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We already have a tag for "mathishard".  What we really need is a "cryptoishard" tag.  As you point out, the actual crypto algorithms are incredibly robust.  What most developers don't pay any attention to is that fact that all the other pieces of the system have to be equally as robust, or you get a trivial crack.</p><p>Most of these systems are brought down by some very humble flaw.  A locked bank vault with the combination hidden under the mat.</p></htmltext>
<tokenext>We already have a tag for " mathishard " .
What we really need is a " cryptoishard " tag .
As you point out , the actual crypto algorithms are incredibly robust .
What most developers do n't pay any attention to is that fact that all the other pieces of the system have to be equally as robust , or you get a trivial crack.Most of these systems are brought down by some very humble flaw .
A locked bank vault with the combination hidden under the mat .</tokentext>
<sentencetext>We already have a tag for "mathishard".
What we really need is a "cryptoishard" tag.
As you point out, the actual crypto algorithms are incredibly robust.
What most developers don't pay any attention to is that fact that all the other pieces of the system have to be equally as robust, or you get a trivial crack.Most of these systems are brought down by some very humble flaw.
A locked bank vault with the combination hidden under the mat.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659020</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30680644</id>
	<title>Re:Insider</title>
	<author>Anonymous</author>
	<datestamp>1262865180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You shouldn't be performing password MATCHING in any case, that's just stupid.</p><p>The password (preferably passphrase) should be used to decrypt the actual encryption key, in which case no matter who handles the password, as without the correct passphrase it's not possible to decrypt the data.</p><p>This has been well-known for decades, what excuse do these companies have for being totally incompetent?</p></htmltext>
<tokenext>You should n't be performing password MATCHING in any case , that 's just stupid.The password ( preferably passphrase ) should be used to decrypt the actual encryption key , in which case no matter who handles the password , as without the correct passphrase it 's not possible to decrypt the data.This has been well-known for decades , what excuse do these companies have for being totally incompetent ?</tokentext>
<sentencetext>You shouldn't be performing password MATCHING in any case, that's just stupid.The password (preferably passphrase) should be used to decrypt the actual encryption key, in which case no matter who handles the password, as without the correct passphrase it's not possible to decrypt the data.This has been well-known for decades, what excuse do these companies have for being totally incompetent?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658714</id>
	<title>What did Muntz have to say on this ?</title>
	<author>Anonymous</author>
	<datestamp>1262721360000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Hahah !!  Winders suxors !!</p><p><a href="http://upload.wikimedia.org/wikipedia/en/c/c6/Nelson\_Muntz.png" title="wikimedia.org" rel="nofollow">http://upload.wikimedia.org/wikipedia/en/c/c6/Nelson\_Muntz.png</a> [wikimedia.org]</p></htmltext>
<tokenext>Hahah ! !
Winders suxors !
! http : //upload.wikimedia.org/wikipedia/en/c/c6/Nelson \ _Muntz.png [ wikimedia.org ]</tokentext>
<sentencetext>Hahah !!
Winders suxors !
!http://upload.wikimedia.org/wikipedia/en/c/c6/Nelson\_Muntz.png [wikimedia.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658804</id>
	<title>Re:Not completely hardware based encryption then?</title>
	<author>Anonymous</author>
	<datestamp>1262721660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What difference does it make?  As long as the data is really encrypted on the drive, either way the cpu is going to have access to the plain text, and in some ways it's better to do the encryption on the cpu: no plaintext over USB foils usb-attached listening devices.  Depending on how it's implemented and what you need the data for, it's even possible to never have plaintext in RAM.</p><p>The article seems to imply that the data is not, in fact, stored on the drive using the claimed AES cipher, or if it is, the password that the user enters is not used to generate the key, but instead used to authorize use of a stored key, which may in fact be exactly the same for all affected devices.</p></htmltext>
<tokenext>What difference does it make ?
As long as the data is really encrypted on the drive , either way the cpu is going to have access to the plain text , and in some ways it 's better to do the encryption on the cpu : no plaintext over USB foils usb-attached listening devices .
Depending on how it 's implemented and what you need the data for , it 's even possible to never have plaintext in RAM.The article seems to imply that the data is not , in fact , stored on the drive using the claimed AES cipher , or if it is , the password that the user enters is not used to generate the key , but instead used to authorize use of a stored key , which may in fact be exactly the same for all affected devices .</tokentext>
<sentencetext>What difference does it make?
As long as the data is really encrypted on the drive, either way the cpu is going to have access to the plain text, and in some ways it's better to do the encryption on the cpu: no plaintext over USB foils usb-attached listening devices.
Depending on how it's implemented and what you need the data for, it's even possible to never have plaintext in RAM.The article seems to imply that the data is not, in fact, stored on the drive using the claimed AES cipher, or if it is, the password that the user enters is not used to generate the key, but instead used to authorize use of a stored key, which may in fact be exactly the same for all affected devices.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30706984</id>
	<title>Just a simple back door is all</title>
	<author>Aging\_Newbie</author>
	<datestamp>1263049560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>They just discovered a back door for the convenience of the IT folks.</p><p>"The reason current FIPS standards don't defend against the vulnerability is because in a corporate environment, being able to unlock and manage hundreds of USB flash drives with a single administrative password is useful, Jevans noted, "which is effectively what this vulnerability is."</p><p>The device password, which is unlocked by a user password, is built into the software that resides on all of the USB drives."</p><p>One password to unlock them all.  Better be sure to make it a real strong one<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>They just discovered a back door for the convenience of the IT folks .
" The reason current FIPS standards do n't defend against the vulnerability is because in a corporate environment , being able to unlock and manage hundreds of USB flash drives with a single administrative password is useful , Jevans noted , " which is effectively what this vulnerability is .
" The device password , which is unlocked by a user password , is built into the software that resides on all of the USB drives .
" One password to unlock them all .
Better be sure to make it a real strong one : - )</tokentext>
<sentencetext>They just discovered a back door for the convenience of the IT folks.
"The reason current FIPS standards don't defend against the vulnerability is because in a corporate environment, being able to unlock and manage hundreds of USB flash drives with a single administrative password is useful, Jevans noted, "which is effectively what this vulnerability is.
"The device password, which is unlocked by a user password, is built into the software that resides on all of the USB drives.
"One password to unlock them all.
Better be sure to make it a real strong one :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658482</id>
	<title>Oops.</title>
	<author>Anonymous</author>
	<datestamp>1262720580000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>Looks like they forgot the ROT13</htmltext>
<tokenext>Looks like they forgot the ROT13</tokentext>
<sentencetext>Looks like they forgot the ROT13</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665260</id>
	<title>Doesn't matter to the Government anyways!</title>
	<author>Anonymous</author>
	<datestamp>1262709900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Who cares, the Military realized that USB drives were unsecure no matter how you tried to "protect" them, and ordered that we stop using them over a year ago.  Besides the security threat, it is an easy way to introduce dangerous software locally onto a system.</p></htmltext>
<tokenext>Who cares , the Military realized that USB drives were unsecure no matter how you tried to " protect " them , and ordered that we stop using them over a year ago .
Besides the security threat , it is an easy way to introduce dangerous software locally onto a system .</tokentext>
<sentencetext>Who cares, the Military realized that USB drives were unsecure no matter how you tried to "protect" them, and ordered that we stop using them over a year ago.
Besides the security threat, it is an easy way to introduce dangerous software locally onto a system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659752</id>
	<title>Re:Truecrypt</title>
	<author>sjames</author>
	<datestamp>1262682960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You'd of course have to be a complete idiot to design an authenticating mechanism in this manner. TrueCrypt does not share this design.</p></div><p>Strongly agreed! This tells me that none of those vendors can be trusted. NIST also cannot be trusted.</p><p>That sort of snake oil is way too common in "secure" USB drives. The first one I personally tested was equally bad. It supposedly used fingerprints to secure the data. It did in a sense, but an incorrect fingerprint just caused the drive to claim it was smaller than it actually was. It would happily allow you to read those sectors past the reported "end of disk" though, so it wasn't exactly secure. The vendor had actually never considered that someone might send raw SCSI commands rather than depend on the standard OS drivers.</p></div>
	</htmltext>
<tokenext>You 'd of course have to be a complete idiot to design an authenticating mechanism in this manner .
TrueCrypt does not share this design.Strongly agreed !
This tells me that none of those vendors can be trusted .
NIST also can not be trusted.That sort of snake oil is way too common in " secure " USB drives .
The first one I personally tested was equally bad .
It supposedly used fingerprints to secure the data .
It did in a sense , but an incorrect fingerprint just caused the drive to claim it was smaller than it actually was .
It would happily allow you to read those sectors past the reported " end of disk " though , so it was n't exactly secure .
The vendor had actually never considered that someone might send raw SCSI commands rather than depend on the standard OS drivers .</tokentext>
<sentencetext>You'd of course have to be a complete idiot to design an authenticating mechanism in this manner.
TrueCrypt does not share this design.Strongly agreed!
This tells me that none of those vendors can be trusted.
NIST also cannot be trusted.That sort of snake oil is way too common in "secure" USB drives.
The first one I personally tested was equally bad.
It supposedly used fingerprints to secure the data.
It did in a sense, but an incorrect fingerprint just caused the drive to claim it was smaller than it actually was.
It would happily allow you to read those sectors past the reported "end of disk" though, so it wasn't exactly secure.
The vendor had actually never considered that someone might send raw SCSI commands rather than depend on the standard OS drivers.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659374</id>
	<title>-c0m</title>
	<author>Anonymous</author>
	<datestamp>1262724420000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>get tough. I  hope Problems with</htmltext>
<tokenext>get tough .
I hope Problems with</tokentext>
<sentencetext>get tough.
I  hope Problems with</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659338</id>
	<title>Re:Truecrypt</title>
	<author>Anonymous</author>
	<datestamp>1262724240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Similarly, you'd have to be a complete idiot to give such devices any kind of certification. We all know that companies can sell any junk they want, that's why we rely on certification agencies. But now we know that certification agencies really work as marketing agencies, boosting the sale of junk hardware by sticking their logo on it.</htmltext>
<tokenext>Similarly , you 'd have to be a complete idiot to give such devices any kind of certification .
We all know that companies can sell any junk they want , that 's why we rely on certification agencies .
But now we know that certification agencies really work as marketing agencies , boosting the sale of junk hardware by sticking their logo on it .</tokentext>
<sentencetext>Similarly, you'd have to be a complete idiot to give such devices any kind of certification.
We all know that companies can sell any junk they want, that's why we rely on certification agencies.
But now we know that certification agencies really work as marketing agencies, boosting the sale of junk hardware by sticking their logo on it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30667228</id>
	<title>Re:Hmm</title>
	<author>Slashcrap</author>
	<datestamp>1262774820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Still, in a sci fi story I am working, a group of terrorists are able to get physical access to the equipment in a missile silo, and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment.</p></div><p>Are you going to bother finishing it? Only with plot points like that it sounds like it's going to be a load of old shit.</p></div>
	</htmltext>
<tokenext>Still , in a sci fi story I am working , a group of terrorists are able to get physical access to the equipment in a missile silo , and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment.Are you going to bother finishing it ?
Only with plot points like that it sounds like it 's going to be a load of old shit .</tokentext>
<sentencetext>Still, in a sci fi story I am working, a group of terrorists are able to get physical access to the equipment in a missile silo, and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment.Are you going to bother finishing it?
Only with plot points like that it sounds like it's going to be a load of old shit.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658742</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262721420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>If you set up Truecrypt in portable-mode on a USB key so it acts like these off-the-shelf keys, then it needs administrator privileges to work. That's a big problem for a lot of people.</p></htmltext>
<tokenext>If you set up Truecrypt in portable-mode on a USB key so it acts like these off-the-shelf keys , then it needs administrator privileges to work .
That 's a big problem for a lot of people .</tokentext>
<sentencetext>If you set up Truecrypt in portable-mode on a USB key so it acts like these off-the-shelf keys, then it needs administrator privileges to work.
That's a big problem for a lot of people.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659532</id>
	<title>imho</title>
	<author>hellraizer</author>
	<datestamp>1262725080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>if you are that worried about the security of your data , don't allow usb flash drives , period...</htmltext>
<tokenext>if you are that worried about the security of your data , do n't allow usb flash drives , period.. .</tokentext>
<sentencetext>if you are that worried about the security of your data , don't allow usb flash drives , period...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30680608</id>
	<title>Re:Article title misleading...</title>
	<author>Anonymous</author>
	<datestamp>1262864700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>No, it seems more like the method the program uses to authorize decryption is flawed.  Anything that program does or could possibly do should never ever break the cryptosystem.  Knowing how any part of the system works shouldn't break the cryptosystem.</p><p>The key should either come from the passphrase directly or (better) be decrypted by it at the time of authentication.</p><p>No proper cryptosystem has any part where one component says to another "it's ok to decrypt" without needing to specify the key.</p></htmltext>
<tokenext>No , it seems more like the method the program uses to authorize decryption is flawed .
Anything that program does or could possibly do should never ever break the cryptosystem .
Knowing how any part of the system works should n't break the cryptosystem.The key should either come from the passphrase directly or ( better ) be decrypted by it at the time of authentication.No proper cryptosystem has any part where one component says to another " it 's ok to decrypt " without needing to specify the key .</tokentext>
<sentencetext>No, it seems more like the method the program uses to authorize decryption is flawed.
Anything that program does or could possibly do should never ever break the cryptosystem.
Knowing how any part of the system works shouldn't break the cryptosystem.The key should either come from the passphrase directly or (better) be decrypted by it at the time of authentication.No proper cryptosystem has any part where one component says to another "it's ok to decrypt" without needing to specify the key.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662086</id>
	<title>Re:Article title misleading...</title>
	<author>zuperduperman</author>
	<datestamp>1262692260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The whole point of encryption is that no amount of software manipulation can bypass it.   The data simply cannot be decoded without the key.  If the software can bypass the encryption without the key under any circumstances then the encryption has been broken or didn't exist in the first place.</p></htmltext>
<tokenext>The whole point of encryption is that no amount of software manipulation can bypass it .
The data simply can not be decoded without the key .
If the software can bypass the encryption without the key under any circumstances then the encryption has been broken or did n't exist in the first place .</tokentext>
<sentencetext>The whole point of encryption is that no amount of software manipulation can bypass it.
The data simply cannot be decoded without the key.
If the software can bypass the encryption without the key under any circumstances then the encryption has been broken or didn't exist in the first place.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659118</id>
	<title>backdoor</title>
	<author>Anonymous</author>
	<datestamp>1262723340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>so all their usb drives use a stored key to encrypt the data ( let me guess, it's the same for all the usb sticks ), but the user does use a password, therefore thinking that the key is unique. Alas, the password just authorizes access to the stored secret key. Sounds like a scam to me, or a backdoor on purpose (<nobr> <wbr></nobr>.. cough N cough S cough A ).</p></htmltext>
<tokenext>so all their usb drives use a stored key to encrypt the data ( let me guess , it 's the same for all the usb sticks ) , but the user does use a password , therefore thinking that the key is unique .
Alas , the password just authorizes access to the stored secret key .
Sounds like a scam to me , or a backdoor on purpose ( .. cough N cough S cough A ) .</tokentext>
<sentencetext>so all their usb drives use a stored key to encrypt the data ( let me guess, it's the same for all the usb sticks ), but the user does use a password, therefore thinking that the key is unique.
Alas, the password just authorizes access to the stored secret key.
Sounds like a scam to me, or a backdoor on purpose ( .. cough N cough S cough A ).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30664726</id>
	<title>Re:IronKey?</title>
	<author>Anonymous</author>
	<datestamp>1262706660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>IronKey looks cool, but even it doesn't solve the untrusted host problem.  If you plug your USB key into an untrusted machine and type in your password, then all bets are off -- the machine may be logging your keystrokes, or recording the screen.  Or just making a copy of all of the unencrypted bits as you access them.</p><p>The only way to be sure that your encrypted data is still *yours* is to make sure you only access it on a computer that you trust. Too bad no one has invented one yet.</p></htmltext>
<tokenext>IronKey looks cool , but even it does n't solve the untrusted host problem .
If you plug your USB key into an untrusted machine and type in your password , then all bets are off -- the machine may be logging your keystrokes , or recording the screen .
Or just making a copy of all of the unencrypted bits as you access them.The only way to be sure that your encrypted data is still * yours * is to make sure you only access it on a computer that you trust .
Too bad no one has invented one yet .</tokentext>
<sentencetext>IronKey looks cool, but even it doesn't solve the untrusted host problem.
If you plug your USB key into an untrusted machine and type in your password, then all bets are off -- the machine may be logging your keystrokes, or recording the screen.
Or just making a copy of all of the unencrypted bits as you access them.The only way to be sure that your encrypted data is still *yours* is to make sure you only access it on a computer that you trust.
Too bad no one has invented one yet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660360</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660464</id>
	<title>Expensive Lock, Cheap Casing</title>
	<author>driftingwalrus</author>
	<datestamp>1262685420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is like having a bank vault, and investing thousands in an expensive lock - then placing that lock on the outside of the vault in a tin box.  All they have to do is smash off the box and turn the knob behind it.  There's a word for this: incompetence.  I'm not sure why companies still put up with this kind of stupidity.  Seriously, if a doctor pulled this kind of stunt he'd lose his license.</p></htmltext>
<tokenext>This is like having a bank vault , and investing thousands in an expensive lock - then placing that lock on the outside of the vault in a tin box .
All they have to do is smash off the box and turn the knob behind it .
There 's a word for this : incompetence .
I 'm not sure why companies still put up with this kind of stupidity .
Seriously , if a doctor pulled this kind of stunt he 'd lose his license .</tokentext>
<sentencetext>This is like having a bank vault, and investing thousands in an expensive lock - then placing that lock on the outside of the vault in a tin box.
All they have to do is smash off the box and turn the knob behind it.
There's a word for this: incompetence.
I'm not sure why companies still put up with this kind of stupidity.
Seriously, if a doctor pulled this kind of stunt he'd lose his license.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660388</id>
	<title>Re:It's not just the algorithm</title>
	<author>Anonymous</author>
	<datestamp>1262685180000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>I used to do FIPS, Common Criteria and Interac certifications.<br>For starts we were paid by the manufacturer of the device so every device passed.  There was one case where a product was so obviously flawed we decided not to take the money and they device was certified by another certification shop.<br>Second, the cost for the certification is fairly competitive and the competition has driven the price down to the point where the money paid just barely covers doing the paper work.  The actual investigation of the devices or software is only hours.<br>Third, NIST is extremely sloppy in checking up on the certification houses.  They are even sloppy about verifying their own tools for doing known answer tests for well know algorithms.</p></htmltext>
<tokenext>I used to do FIPS , Common Criteria and Interac certifications.For starts we were paid by the manufacturer of the device so every device passed .
There was one case where a product was so obviously flawed we decided not to take the money and they device was certified by another certification shop.Second , the cost for the certification is fairly competitive and the competition has driven the price down to the point where the money paid just barely covers doing the paper work .
The actual investigation of the devices or software is only hours.Third , NIST is extremely sloppy in checking up on the certification houses .
They are even sloppy about verifying their own tools for doing known answer tests for well know algorithms .</tokentext>
<sentencetext>I used to do FIPS, Common Criteria and Interac certifications.For starts we were paid by the manufacturer of the device so every device passed.
There was one case where a product was so obviously flawed we decided not to take the money and they device was certified by another certification shop.Second, the cost for the certification is fairly competitive and the competition has driven the price down to the point where the money paid just barely covers doing the paper work.
The actual investigation of the devices or software is only hours.Third, NIST is extremely sloppy in checking up on the certification houses.
They are even sloppy about verifying their own tools for doing known answer tests for well know algorithms.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658610</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262721060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.nytimes.com/2010/01/04/technology/04video.html" title="nytimes.com" rel="nofollow">&ldquo;Consumers shouldn&rsquo;t have to know what&rsquo;s inside,&rdquo; he said. &ldquo;They should just know it will play.&rdquo;</a> [nytimes.com]  What applies to entertainment for the drooling masses also applies to security for the drooling masses.</p></htmltext>
<tokenext>   Consumers shouldn    t have to know what    s inside ,    he said .
   They should just know it will play.    [ nytimes.com ] What applies to entertainment for the drooling masses also applies to security for the drooling masses .</tokentext>
<sentencetext>“Consumers shouldn’t have to know what’s inside,” he said.
“They should just know it will play.” [nytimes.com]  What applies to entertainment for the drooling masses also applies to security for the drooling masses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430</id>
	<title>It's not just the algorithm</title>
	<author>Anonymous</author>
	<datestamp>1262720400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>One weakness in the entire crypto-<b>system</b> can bring the whole thing down.</p></htmltext>
<tokenext>One weakness in the entire crypto-system can bring the whole thing down .</tokentext>
<sentencetext>One weakness in the entire crypto-system can bring the whole thing down.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658660</id>
	<title>Re:IronKey?</title>
	<author>Wingman 5</author>
	<datestamp>1262721180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>No, IronKey uses a hardware crypto chip, these drives are all using software crypto. What this group did was bypass the software crypto.</htmltext>
<tokenext>No , IronKey uses a hardware crypto chip , these drives are all using software crypto .
What this group did was bypass the software crypto .</tokentext>
<sentencetext>No, IronKey uses a hardware crypto chip, these drives are all using software crypto.
What this group did was bypass the software crypto.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774</id>
	<title>Re:Insider</title>
	<author>Anonymous</author>
	<datestamp>1262683080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>1. Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive.</p></div><p>You're assuming your short production run / limited power / simple architecture / limited heat dissipation hardware is faster than running it in software on a commodity processor, which RAID card manufacturers have falsely been pushing for years (decades now?).  Think about it, it implies a USB sized and USB powered gadget runs faster than the PC its plugged into.</p><p>Also assumes the limiter to overall system speed is processing the data.  Feeding "a couple megs" to a multicore processor running "several gigs" is not going to saturate it... The processor is going to spend most of its time doing something else.</p><p>Not to say HW encryption isn't a good idea from a security standpoint.</p><p>Or if, in some crazy world, the drive is attached to something that is actually lower powered than the flash drive (maybe a data logger appliance or something) then it makes sense.</p><p>Or, if the add on device has a special ATX connector so it can suck down almost as much power as the CPU, like modern video cards, and is hyper parallelizable like a modern video card, then "doing it in dedicated HW" makes sense.</p><p>But in general, always a bad idea to replicate what the main processor already does, but badly or more slowly.</p></div>
	</htmltext>
<tokenext>1 .
Performance is sacrificed since your PC CPU needs to perform all security operations in software , rather than on the hardware of the flash drive.You 're assuming your short production run / limited power / simple architecture / limited heat dissipation hardware is faster than running it in software on a commodity processor , which RAID card manufacturers have falsely been pushing for years ( decades now ? ) .
Think about it , it implies a USB sized and USB powered gadget runs faster than the PC its plugged into.Also assumes the limiter to overall system speed is processing the data .
Feeding " a couple megs " to a multicore processor running " several gigs " is not going to saturate it... The processor is going to spend most of its time doing something else.Not to say HW encryption is n't a good idea from a security standpoint.Or if , in some crazy world , the drive is attached to something that is actually lower powered than the flash drive ( maybe a data logger appliance or something ) then it makes sense.Or , if the add on device has a special ATX connector so it can suck down almost as much power as the CPU , like modern video cards , and is hyper parallelizable like a modern video card , then " doing it in dedicated HW " makes sense.But in general , always a bad idea to replicate what the main processor already does , but badly or more slowly .</tokentext>
<sentencetext>1.
Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive.You're assuming your short production run / limited power / simple architecture / limited heat dissipation hardware is faster than running it in software on a commodity processor, which RAID card manufacturers have falsely been pushing for years (decades now?).
Think about it, it implies a USB sized and USB powered gadget runs faster than the PC its plugged into.Also assumes the limiter to overall system speed is processing the data.
Feeding "a couple megs" to a multicore processor running "several gigs" is not going to saturate it... The processor is going to spend most of its time doing something else.Not to say HW encryption isn't a good idea from a security standpoint.Or if, in some crazy world, the drive is attached to something that is actually lower powered than the flash drive (maybe a data logger appliance or something) then it makes sense.Or, if the add on device has a special ATX connector so it can suck down almost as much power as the CPU, like modern video cards, and is hyper parallelizable like a modern video card, then "doing it in dedicated HW" makes sense.But in general, always a bad idea to replicate what the main processor already does, but badly or more slowly.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30668904</id>
	<title>Re:Hmm</title>
	<author>Chili-71</author>
	<datestamp>1262790180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Having spent 8 years in the Naval Security Group working with NSA and another 10 years as a defense contractor working with NSA on secure communications, I can tell you for a fact that if you don't have physical security, you don't have security. Period.</htmltext>
<tokenext>Having spent 8 years in the Naval Security Group working with NSA and another 10 years as a defense contractor working with NSA on secure communications , I can tell you for a fact that if you do n't have physical security , you do n't have security .
Period .</tokentext>
<sentencetext>Having spent 8 years in the Naval Security Group working with NSA and another 10 years as a defense contractor working with NSA on secure communications, I can tell you for a fact that if you don't have physical security, you don't have security.
Period.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659142</id>
	<title>Re:Article title misleading...</title>
	<author>Anonymous</author>
	<datestamp>1262723460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This "encryption" is just as effective as locking one's door with the most powerful locks available while leaving the window wide open...

As someone else said: the unlock program is irrelevant. The security must be in the USB stick. But it obviously isn't, hence the device (if not the "encryption" per se) has been cracked.</htmltext>
<tokenext>This " encryption " is just as effective as locking one 's door with the most powerful locks available while leaving the window wide open.. . As someone else said : the unlock program is irrelevant .
The security must be in the USB stick .
But it obviously is n't , hence the device ( if not the " encryption " per se ) has been cracked .</tokentext>
<sentencetext>This "encryption" is just as effective as locking one's door with the most powerful locks available while leaving the window wide open...

As someone else said: the unlock program is irrelevant.
The security must be in the USB stick.
But it obviously isn't, hence the device (if not the "encryption" per se) has been cracked.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659408</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>plover</author>
	<datestamp>1262724540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>While I agree that trust belongs on the device (via a device-based keyboard), you still have to trust the host computer to not abuse the trust by copying the now-unlocked data or otherwise tampering with it.  You are still at risk if you unlock the device and plug it in to a coffee shop PC.</p></htmltext>
<tokenext>While I agree that trust belongs on the device ( via a device-based keyboard ) , you still have to trust the host computer to not abuse the trust by copying the now-unlocked data or otherwise tampering with it .
You are still at risk if you unlock the device and plug it in to a coffee shop PC .</tokentext>
<sentencetext>While I agree that trust belongs on the device (via a device-based keyboard), you still have to trust the host computer to not abuse the trust by copying the now-unlocked data or otherwise tampering with it.
You are still at risk if you unlock the device and plug it in to a coffee shop PC.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665730</id>
	<title>Re:Truecrypt</title>
	<author>uninformedLuddite</author>
	<datestamp>1262714280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You'd of course have to be a complete idiot to design an authenticating mechanism in this manner. TrueCrypt does not share this design.</p></div><p>What is even more worrying is that this device actually complied with some/any official standard. It doesn't matter which standard. it demonstrates that the device's method of keeping your data safe is retarded. Also that those who make and regulate these standards are also retarded.<br>
How many people would have kept confidential data on these things due to a mistaken belief that the standards themselves aren't broken let alone the device that has been certified as complying with them.</p></div>
	</htmltext>
<tokenext>You 'd of course have to be a complete idiot to design an authenticating mechanism in this manner .
TrueCrypt does not share this design.What is even more worrying is that this device actually complied with some/any official standard .
It does n't matter which standard .
it demonstrates that the device 's method of keeping your data safe is retarded .
Also that those who make and regulate these standards are also retarded .
How many people would have kept confidential data on these things due to a mistaken belief that the standards themselves are n't broken let alone the device that has been certified as complying with them .</tokentext>
<sentencetext>You'd of course have to be a complete idiot to design an authenticating mechanism in this manner.
TrueCrypt does not share this design.What is even more worrying is that this device actually complied with some/any official standard.
It doesn't matter which standard.
it demonstrates that the device's method of keeping your data safe is retarded.
Also that those who make and regulate these standards are also retarded.
How many people would have kept confidential data on these things due to a mistaken belief that the standards themselves aren't broken let alone the device that has been certified as complying with them.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068</id>
	<title>Who cares?</title>
	<author>static416</author>
	<datestamp>1262723100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Every time anyone discovers some tiny vulnerability in any computer security system (WPA, TKIP, AES, etc) nerds everywhere leap into action, spreading FUD while shunning the now flawed protocol and anyone who still chooses to use it.</p><p>But the reality is that for almost everyone, the flawed protocol is still fine. Most people only need to protect their data from another average computer user, not a hacker, sophisticated encryption-cracking security firm or a government.</p><p>It's like locking your car or your house. It's really only designed to keep honest people honest.</p><p>So please don't go scaring the ignorant needlessly. I don't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she shouldn't be concerned. All I get out of that transaction is a confused and paranoid mother whose password is still her last name.</p></htmltext>
<tokenext>Every time anyone discovers some tiny vulnerability in any computer security system ( WPA , TKIP , AES , etc ) nerds everywhere leap into action , spreading FUD while shunning the now flawed protocol and anyone who still chooses to use it.But the reality is that for almost everyone , the flawed protocol is still fine .
Most people only need to protect their data from another average computer user , not a hacker , sophisticated encryption-cracking security firm or a government.It 's like locking your car or your house .
It 's really only designed to keep honest people honest.So please do n't go scaring the ignorant needlessly .
I do n't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she should n't be concerned .
All I get out of that transaction is a confused and paranoid mother whose password is still her last name .</tokentext>
<sentencetext>Every time anyone discovers some tiny vulnerability in any computer security system (WPA, TKIP, AES, etc) nerds everywhere leap into action, spreading FUD while shunning the now flawed protocol and anyone who still chooses to use it.But the reality is that for almost everyone, the flawed protocol is still fine.
Most people only need to protect their data from another average computer user, not a hacker, sophisticated encryption-cracking security firm or a government.It's like locking your car or your house.
It's really only designed to keep honest people honest.So please don't go scaring the ignorant needlessly.
I don't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she shouldn't be concerned.
All I get out of that transaction is a confused and paranoid mother whose password is still her last name.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30664012</id>
	<title>Re:Insider</title>
	<author>Anonymous</author>
	<datestamp>1262701800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You fail understanding hardware forever.</p><p>Dedicated hardware is just about <em>always</em> faster (and less power intensive) than <em>general purpose</em> hardware simply because the general purpose hardware cannot be optimised for the specific task.</p><p>Why do you think that a CISC instruction set program being translated by a RISC instruction set microcode program executing on a CPU core connected to the disk by 3 layers of general purpose buses (CPU Frontside, PCI, USB) would be faster than a dedicated chip connected directly to the flash via a special purpose bus?</p><p>You do realise that the dedicated computer chips in your digital watch use less power tracking time then the CPU in your desktop system would, right?</p></htmltext>
<tokenext>You fail understanding hardware forever.Dedicated hardware is just about always faster ( and less power intensive ) than general purpose hardware simply because the general purpose hardware can not be optimised for the specific task.Why do you think that a CISC instruction set program being translated by a RISC instruction set microcode program executing on a CPU core connected to the disk by 3 layers of general purpose buses ( CPU Frontside , PCI , USB ) would be faster than a dedicated chip connected directly to the flash via a special purpose bus ? You do realise that the dedicated computer chips in your digital watch use less power tracking time then the CPU in your desktop system would , right ?</tokentext>
<sentencetext>You fail understanding hardware forever.Dedicated hardware is just about always faster (and less power intensive) than general purpose hardware simply because the general purpose hardware cannot be optimised for the specific task.Why do you think that a CISC instruction set program being translated by a RISC instruction set microcode program executing on a CPU core connected to the disk by 3 layers of general purpose buses (CPU Frontside, PCI, USB) would be faster than a dedicated chip connected directly to the flash via a special purpose bus?You do realise that the dedicated computer chips in your digital watch use less power tracking time then the CPU in your desktop system would, right?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661658</id>
	<title>Re:IronKey?</title>
	<author>owlstead</author>
	<datestamp>1262690280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Nah, the ironkey is made from aluminium not from wood (tree products, could not pass the pun). Having looked at the ironkey protocols they seem quite sturdy. Actually it is the only USB-key device I would buy for myself for secure storage - even though even those drives have key distro problems (how do you trust the ironkey that is in your mail, for instance).</p></htmltext>
<tokenext>Nah , the ironkey is made from aluminium not from wood ( tree products , could not pass the pun ) .
Having looked at the ironkey protocols they seem quite sturdy .
Actually it is the only USB-key device I would buy for myself for secure storage - even though even those drives have key distro problems ( how do you trust the ironkey that is in your mail , for instance ) .</tokentext>
<sentencetext>Nah, the ironkey is made from aluminium not from wood (tree products, could not pass the pun).
Having looked at the ironkey protocols they seem quite sturdy.
Actually it is the only USB-key device I would buy for myself for secure storage - even though even those drives have key distro problems (how do you trust the ironkey that is in your mail, for instance).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659020</id>
	<title>Re:It's not just the algorithm</title>
	<author>hey!</author>
	<datestamp>1262722860000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Only? It's *mainly* defects in the rest of the system that tend to bring things down.</p><p>Algorithms, once they get to the point where the experts trust them, are very seldom broken in the everything-laid-completely-bare way that faulty system design gets you. It's usually more like "could be broken with a week of supercomputing time ten years from now" or "can calculate a hash collision for certain specially constructed messages" variety of crack.</p><p>Of course once you get to that point, you have to assume that some really bright people will find a way to generalize the fault in the algorithm.   If they'd broken  AES, or even found an unexpected weakness in it, that'd be *huge* news. Instead, what they've found appears to be a classic case of plain old brain damaged design.</p><p>If the article is to be believed, the researchers found a really, really stupid flaw, the kind a non-expert like I could understand and probably exploit with not much effort. I would paraphrase this way: all these drives *effectively* have exactly the same key, but that fact is obscured by the software.</p></htmltext>
<tokenext>Only ?
It 's * mainly * defects in the rest of the system that tend to bring things down.Algorithms , once they get to the point where the experts trust them , are very seldom broken in the everything-laid-completely-bare way that faulty system design gets you .
It 's usually more like " could be broken with a week of supercomputing time ten years from now " or " can calculate a hash collision for certain specially constructed messages " variety of crack.Of course once you get to that point , you have to assume that some really bright people will find a way to generalize the fault in the algorithm .
If they 'd broken AES , or even found an unexpected weakness in it , that 'd be * huge * news .
Instead , what they 've found appears to be a classic case of plain old brain damaged design.If the article is to be believed , the researchers found a really , really stupid flaw , the kind a non-expert like I could understand and probably exploit with not much effort .
I would paraphrase this way : all these drives * effectively * have exactly the same key , but that fact is obscured by the software .</tokentext>
<sentencetext>Only?
It's *mainly* defects in the rest of the system that tend to bring things down.Algorithms, once they get to the point where the experts trust them, are very seldom broken in the everything-laid-completely-bare way that faulty system design gets you.
It's usually more like "could be broken with a week of supercomputing time ten years from now" or "can calculate a hash collision for certain specially constructed messages" variety of crack.Of course once you get to that point, you have to assume that some really bright people will find a way to generalize the fault in the algorithm.
If they'd broken  AES, or even found an unexpected weakness in it, that'd be *huge* news.
Instead, what they've found appears to be a classic case of plain old brain damaged design.If the article is to be believed, the researchers found a really, really stupid flaw, the kind a non-expert like I could understand and probably exploit with not much effort.
I would paraphrase this way: all these drives *effectively* have exactly the same key, but that fact is obscured by the software.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642</id>
	<title>Re:Shouldn't trust the host computer AT ALL</title>
	<author>Lord Ender</author>
	<datestamp>1262682360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is stupid. A password must be 20 random characters MINIMUM to provide just 128 bit key strength. Nobody's going to type such long passwords on a tiny thumb-drive keyboard all the time.</p></htmltext>
<tokenext>This is stupid .
A password must be 20 random characters MINIMUM to provide just 128 bit key strength .
Nobody 's going to type such long passwords on a tiny thumb-drive keyboard all the time .</tokentext>
<sentencetext>This is stupid.
A password must be 20 random characters MINIMUM to provide just 128 bit key strength.
Nobody's going to type such long passwords on a tiny thumb-drive keyboard all the time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</id>
	<title>Insider</title>
	<author>dbrez8</author>
	<datestamp>1262723700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>As someone who works in the secure flash drive space, maybe I can shed a little light on some questions/comments I see above..<br>
<br>
First and foremost the vulnerability described in this article is related to only the secure flash drives stated in TFA. There are several others available that do not have this vulnerability because instead of password matching in software, they match in Hardware of Firmware, run on the drive itself. Are there others within the industry that may be susceptible? Probably, but all secure flash drives certainly are not. Look to only use drives with password matching done on-chip (HW/FW).<br>
<br>
How could a FIPS 140-2 certified flash drive have this vulnerability? Well FIPS is great to prove you use certified encryption algorithms, authentication methods, and so on, but FIPS does not certify the whole system. This is one of those very important security areas that fall outside of the FIPS umbrella. In the future look for additional certifications that will encompass the entire system rather than just the encryption like FIPS..<br>
<br>
Why not just use TrueCrypt?? TrueCrypt is a great product, there is no doubt. But at its core, TrueCrypt is a software encryption container for your data. There are some inherent shortcomings with software encryption on USB flash drives. <br>
1. Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive. <br>
2. Though it may work well for consumers that *want* to have their data secure, TrueCrypt would be a nightmare in an enterprise setting. Users could format the drive, or store files outside of the encrypted partition just to make things easier. This is not possible on secure flash drives with forced data encryption via hardware. with these drives an Admin knows that if he sees a drive by company X, that the data on it must be secure.
Just to name a couple..<br>
<br>
I hope this is helpful to some.</htmltext>
<tokenext>As someone who works in the secure flash drive space , maybe I can shed a little light on some questions/comments I see above. . First and foremost the vulnerability described in this article is related to only the secure flash drives stated in TFA .
There are several others available that do not have this vulnerability because instead of password matching in software , they match in Hardware of Firmware , run on the drive itself .
Are there others within the industry that may be susceptible ?
Probably , but all secure flash drives certainly are not .
Look to only use drives with password matching done on-chip ( HW/FW ) .
How could a FIPS 140-2 certified flash drive have this vulnerability ?
Well FIPS is great to prove you use certified encryption algorithms , authentication methods , and so on , but FIPS does not certify the whole system .
This is one of those very important security areas that fall outside of the FIPS umbrella .
In the future look for additional certifications that will encompass the entire system rather than just the encryption like FIPS. . Why not just use TrueCrypt ? ?
TrueCrypt is a great product , there is no doubt .
But at its core , TrueCrypt is a software encryption container for your data .
There are some inherent shortcomings with software encryption on USB flash drives .
1. Performance is sacrificed since your PC CPU needs to perform all security operations in software , rather than on the hardware of the flash drive .
2. Though it may work well for consumers that * want * to have their data secure , TrueCrypt would be a nightmare in an enterprise setting .
Users could format the drive , or store files outside of the encrypted partition just to make things easier .
This is not possible on secure flash drives with forced data encryption via hardware .
with these drives an Admin knows that if he sees a drive by company X , that the data on it must be secure .
Just to name a couple. . I hope this is helpful to some .</tokentext>
<sentencetext>As someone who works in the secure flash drive space, maybe I can shed a little light on some questions/comments I see above..

First and foremost the vulnerability described in this article is related to only the secure flash drives stated in TFA.
There are several others available that do not have this vulnerability because instead of password matching in software, they match in Hardware of Firmware, run on the drive itself.
Are there others within the industry that may be susceptible?
Probably, but all secure flash drives certainly are not.
Look to only use drives with password matching done on-chip (HW/FW).
How could a FIPS 140-2 certified flash drive have this vulnerability?
Well FIPS is great to prove you use certified encryption algorithms, authentication methods, and so on, but FIPS does not certify the whole system.
This is one of those very important security areas that fall outside of the FIPS umbrella.
In the future look for additional certifications that will encompass the entire system rather than just the encryption like FIPS..

Why not just use TrueCrypt??
TrueCrypt is a great product, there is no doubt.
But at its core, TrueCrypt is a software encryption container for your data.
There are some inherent shortcomings with software encryption on USB flash drives.
1. Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive.
2. Though it may work well for consumers that *want* to have their data secure, TrueCrypt would be a nightmare in an enterprise setting.
Users could format the drive, or store files outside of the encrypted partition just to make things easier.
This is not possible on secure flash drives with forced data encryption via hardware.
with these drives an Admin knows that if he sees a drive by company X, that the data on it must be secure.
Just to name a couple..

I hope this is helpful to some.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658466</id>
	<title>Always sends the same character string</title>
	<author>Anonymous</author>
	<datestamp>1262720520000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>"12345"</p></htmltext>
<tokenext>" 12345 "</tokentext>
<sentencetext>"12345"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665882</id>
	<title>Re:Hmm</title>
	<author>mirix</author>
	<datestamp>1262715600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I always figured things like that would be quadruple redundant, straight hardware. Just ancient TTL gates, primitive, but pretty foolproof. No software as such.</htmltext>
<tokenext>I always figured things like that would be quadruple redundant , straight hardware .
Just ancient TTL gates , primitive , but pretty foolproof .
No software as such .</tokentext>
<sentencetext>I always figured things like that would be quadruple redundant, straight hardware.
Just ancient TTL gates, primitive, but pretty foolproof.
No software as such.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659286</id>
	<title>I don't get it</title>
	<author>Anonymous</author>
	<datestamp>1262724000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why are these self-encrypting thumbdrives so popular? I know I wouldn't trust any of them with my data because obviously they need Windows drivers to even access them reducing platform compatibility and, as has just been proven, reducing security. Why rely on some hardware vendor who might have cut corners?</p><p>Is it really so hard to run your data through an encryption application before dragging it around?</p><p>Even better. Why are people even allowed/able to access data in this manner? If people are working on some government database and need to take the data somewhere, why not encrypt the data before it leaves the system? This way people will not be able to access it in any way until it reaches the trusted destination where it can be decrypted. People could lose it in the commute or even share all their documents with p2p and it wouldn't matter, provided the encryption scheme and keys are strong enough.</p></htmltext>
<tokenext>Why are these self-encrypting thumbdrives so popular ?
I know I would n't trust any of them with my data because obviously they need Windows drivers to even access them reducing platform compatibility and , as has just been proven , reducing security .
Why rely on some hardware vendor who might have cut corners ? Is it really so hard to run your data through an encryption application before dragging it around ? Even better .
Why are people even allowed/able to access data in this manner ?
If people are working on some government database and need to take the data somewhere , why not encrypt the data before it leaves the system ?
This way people will not be able to access it in any way until it reaches the trusted destination where it can be decrypted .
People could lose it in the commute or even share all their documents with p2p and it would n't matter , provided the encryption scheme and keys are strong enough .</tokentext>
<sentencetext>Why are these self-encrypting thumbdrives so popular?
I know I wouldn't trust any of them with my data because obviously they need Windows drivers to even access them reducing platform compatibility and, as has just been proven, reducing security.
Why rely on some hardware vendor who might have cut corners?Is it really so hard to run your data through an encryption application before dragging it around?Even better.
Why are people even allowed/able to access data in this manner?
If people are working on some government database and need to take the data somewhere, why not encrypt the data before it leaves the system?
This way people will not be able to access it in any way until it reaches the trusted destination where it can be decrypted.
People could lose it in the commute or even share all their documents with p2p and it wouldn't matter, provided the encryption scheme and keys are strong enough.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546</id>
	<title>Article title misleading...</title>
	<author>JazzyJ</author>
	<datestamp>1262720820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.</p></htmltext>
<tokenext>The encryption has n't been cracked , it 's the program that unlocks it that 's been compromised .</tokentext>
<sentencetext>The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504</id>
	<title>IronKey?</title>
	<author>bsDaemon</author>
	<datestamp>1262720700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I got an IronKey from my parents for Christmas.  I haven't used it on a Windows machine yet, just my MacBook Pro and Linux EeePC at home and my iMac at work.  The article doesn't mention whether or not that platform is affected by a similar type of issue or not -- is anyone more familiar with this that can weigh in on that?  I'd be kind of pissed if my brand new toy turns out to just be a toy after all, but IronKey is also FIPS 140-2 certified.  Do the tree products noted just use the same original vender for the encryption?</htmltext>
<tokenext>I got an IronKey from my parents for Christmas .
I have n't used it on a Windows machine yet , just my MacBook Pro and Linux EeePC at home and my iMac at work .
The article does n't mention whether or not that platform is affected by a similar type of issue or not -- is anyone more familiar with this that can weigh in on that ?
I 'd be kind of pissed if my brand new toy turns out to just be a toy after all , but IronKey is also FIPS 140-2 certified .
Do the tree products noted just use the same original vender for the encryption ?</tokentext>
<sentencetext>I got an IronKey from my parents for Christmas.
I haven't used it on a Windows machine yet, just my MacBook Pro and Linux EeePC at home and my iMac at work.
The article doesn't mention whether or not that platform is affected by a similar type of issue or not -- is anyone more familiar with this that can weigh in on that?
I'd be kind of pissed if my brand new toy turns out to just be a toy after all, but IronKey is also FIPS 140-2 certified.
Do the tree products noted just use the same original vender for the encryption?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602</id>
	<title>Not completely hardware based encryption then?</title>
	<author>tibman</author>
	<datestamp>1262721000000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Seems that they did in software what should have been done in the hardware.  The USB hardware should consider itself safe and the host machine suspect.. atleast in my mind.  ATMEL has some good chips like: <a href="http://atmel.com/products/securerf/cryptocompanion.asp?family=646" title="atmel.com">http://atmel.com/products/securerf/cryptocompanion.asp?family=646</a> [atmel.com]</p></htmltext>
<tokenext>Seems that they did in software what should have been done in the hardware .
The USB hardware should consider itself safe and the host machine suspect.. atleast in my mind .
ATMEL has some good chips like : http : //atmel.com/products/securerf/cryptocompanion.asp ? family = 646 [ atmel.com ]</tokentext>
<sentencetext>Seems that they did in software what should have been done in the hardware.
The USB hardware should consider itself safe and the host machine suspect.. atleast in my mind.
ATMEL has some good chips like: http://atmel.com/products/securerf/cryptocompanion.asp?family=646 [atmel.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661352</id>
	<title>Re:Not completely hardware based encryption then?</title>
	<author>leuk\_he</author>
	<datestamp>1262689020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If the password matching was done in hardware it would have been visible that the disk was tampered with. You would have to replace the program that is in dedicated hardware to send the "open" key to the disk. That is much harder to do, even if it had the same vulnerability.</p><p>FIPS-140 2 does not require much resitance to hardware tampering, only that it is visible that it is tampered with. But then how many people loop up the "140-2" spec (even if it is in a link in the article) and just think it is ok to trust a laboratory.  I cannot even find out what labatory F*cked up by looking at the sandisk web.</p></htmltext>
<tokenext>If the password matching was done in hardware it would have been visible that the disk was tampered with .
You would have to replace the program that is in dedicated hardware to send the " open " key to the disk .
That is much harder to do , even if it had the same vulnerability.FIPS-140 2 does not require much resitance to hardware tampering , only that it is visible that it is tampered with .
But then how many people loop up the " 140-2 " spec ( even if it is in a link in the article ) and just think it is ok to trust a laboratory .
I can not even find out what labatory F * cked up by looking at the sandisk web .</tokentext>
<sentencetext>If the password matching was done in hardware it would have been visible that the disk was tampered with.
You would have to replace the program that is in dedicated hardware to send the "open" key to the disk.
That is much harder to do, even if it had the same vulnerability.FIPS-140 2 does not require much resitance to hardware tampering, only that it is visible that it is tampered with.
But then how many people loop up the "140-2" spec (even if it is in a link in the article) and just think it is ok to trust a laboratory.
I cannot even find out what labatory F*cked up by looking at the sandisk web.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658804</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659360</id>
	<title>Re:Who cares?</title>
	<author>bcmm</author>
	<datestamp>1262724360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This isn't like "having a lock to keep honest people honest". It's like putting a lock on your bike which isn't actually attached to anything and hoping nobody looks too closely to keep honest people honest.</htmltext>
<tokenext>This is n't like " having a lock to keep honest people honest " .
It 's like putting a lock on your bike which is n't actually attached to anything and hoping nobody looks too closely to keep honest people honest .</tokentext>
<sentencetext>This isn't like "having a lock to keep honest people honest".
It's like putting a lock on your bike which isn't actually attached to anything and hoping nobody looks too closely to keep honest people honest.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662148</id>
	<title>Re:Insider</title>
	<author>DavidTC</author>
	<datestamp>1262692560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The idea that decryption to/from a USB flash drive would have an CPU effect is laughable.</p><p>
At best, a flash drive is getting read at about 30 MB/s (And written slower).</p><p>
My laptop, a 1.6 Ghz dual processor Intel, can decrypt AES at 100 MB/s. (Incidentally, I have that entire computer encrypted.) My other computer, a 2.1Ghz AMD, gets 230 MB/s.</p><p>
If your CPU cannot do AES at 30 MB/s, or if it's even noticeable, you probably should get a new computer. AES was designed to work on modern processors with minimal CPU.</p><p>
Of course, as 'someone who works in the secure flash drive space', you're probably aware of all that, and just shilling for your rather unneeded industry.</p></htmltext>
<tokenext>The idea that decryption to/from a USB flash drive would have an CPU effect is laughable .
At best , a flash drive is getting read at about 30 MB/s ( And written slower ) .
My laptop , a 1.6 Ghz dual processor Intel , can decrypt AES at 100 MB/s .
( Incidentally , I have that entire computer encrypted .
) My other computer , a 2.1Ghz AMD , gets 230 MB/s .
If your CPU can not do AES at 30 MB/s , or if it 's even noticeable , you probably should get a new computer .
AES was designed to work on modern processors with minimal CPU .
Of course , as 'someone who works in the secure flash drive space ' , you 're probably aware of all that , and just shilling for your rather unneeded industry .</tokentext>
<sentencetext>The idea that decryption to/from a USB flash drive would have an CPU effect is laughable.
At best, a flash drive is getting read at about 30 MB/s (And written slower).
My laptop, a 1.6 Ghz dual processor Intel, can decrypt AES at 100 MB/s.
(Incidentally, I have that entire computer encrypted.
) My other computer, a 2.1Ghz AMD, gets 230 MB/s.
If your CPU cannot do AES at 30 MB/s, or if it's even noticeable, you probably should get a new computer.
AES was designed to work on modern processors with minimal CPU.
Of course, as 'someone who works in the secure flash drive space', you're probably aware of all that, and just shilling for your rather unneeded industry.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659056</id>
	<title>Not so much compromised as badly written.</title>
	<author>OmniGeek</author>
	<datestamp>1262723100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If I understand the article correctly, the access application in effect ignores the entered password, and instead - probably as a result of miserable software design - uses a fixed-string password for the encryption/decryption. In that case, it's not so much a compromise as an own-goal by the fools who wrote and tested (?) the Windows access application. The encryption implementation itself is probably fine if it's given decent keys...</p></htmltext>
<tokenext>If I understand the article correctly , the access application in effect ignores the entered password , and instead - probably as a result of miserable software design - uses a fixed-string password for the encryption/decryption .
In that case , it 's not so much a compromise as an own-goal by the fools who wrote and tested ( ?
) the Windows access application .
The encryption implementation itself is probably fine if it 's given decent keys.. .</tokentext>
<sentencetext>If I understand the article correctly, the access application in effect ignores the entered password, and instead - probably as a result of miserable software design - uses a fixed-string password for the encryption/decryption.
In that case, it's not so much a compromise as an own-goal by the fools who wrote and tested (?
) the Windows access application.
The encryption implementation itself is probably fine if it's given decent keys...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660302</id>
	<title>Re:Who cares?</title>
	<author>Hatta</author>
	<datestamp>1262684880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>I don't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she shouldn't be concerned.</i></p><p>Um, she should be concerned.  WEP might as well be an open access point, in which case anyone can sniff anything that goes over it unencrypted.  All it takes is one person to sniff her email password over the WiFi and they can cause all sorts of headaches.</p><p>What you don't need to do is explain it to her.  Just say "WEP is obsolete garbage, trust me".</p></htmltext>
<tokenext>I do n't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she should n't be concerned.Um , she should be concerned .
WEP might as well be an open access point , in which case anyone can sniff anything that goes over it unencrypted .
All it takes is one person to sniff her email password over the WiFi and they can cause all sorts of headaches.What you do n't need to do is explain it to her .
Just say " WEP is obsolete garbage , trust me " .</tokentext>
<sentencetext>I don't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she shouldn't be concerned.Um, she should be concerned.
WEP might as well be an open access point, in which case anyone can sniff anything that goes over it unencrypted.
All it takes is one person to sniff her email password over the WiFi and they can cause all sorts of headaches.What you don't need to do is explain it to her.
Just say "WEP is obsolete garbage, trust me".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661014</id>
	<title>Re:Insider</title>
	<author>Andy Dodd</author>
	<datestamp>1262687580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem is that it's next to impossible to find these specs.  Hell, with many of these drives it's difficult to identify whether it even has true hardware encryption.</p><p>It's a bad sign when the "flagship" products in three different manufacturer's lines had the key management scheme botched this severely.</p><p>Enterprises designing security are basically screwed now:<br>1)  TrueCrypt has the issue of the fact that, as you say, users can accidentally store stuff unencrypted.  Plus there's the admin rights issue.<br>2)  All of these hardware-based solutions are closed-source/closed-hardware, and as a result don't have the peer review TC does.  Without peer review, you get shit like this incident.</p></htmltext>
<tokenext>The problem is that it 's next to impossible to find these specs .
Hell , with many of these drives it 's difficult to identify whether it even has true hardware encryption.It 's a bad sign when the " flagship " products in three different manufacturer 's lines had the key management scheme botched this severely.Enterprises designing security are basically screwed now : 1 ) TrueCrypt has the issue of the fact that , as you say , users can accidentally store stuff unencrypted .
Plus there 's the admin rights issue.2 ) All of these hardware-based solutions are closed-source/closed-hardware , and as a result do n't have the peer review TC does .
Without peer review , you get shit like this incident .</tokentext>
<sentencetext>The problem is that it's next to impossible to find these specs.
Hell, with many of these drives it's difficult to identify whether it even has true hardware encryption.It's a bad sign when the "flagship" products in three different manufacturer's lines had the key management scheme botched this severely.Enterprises designing security are basically screwed now:1)  TrueCrypt has the issue of the fact that, as you say, users can accidentally store stuff unencrypted.
Plus there's the admin rights issue.2)  All of these hardware-based solutions are closed-source/closed-hardware, and as a result don't have the peer review TC does.
Without peer review, you get shit like this incident.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660560</id>
	<title>let's be clear</title>
	<author>hesaigo999ca</author>
	<datestamp>1262685780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is not to say that they broke the encryption, but just to say they figured out a way to bypass the encryption scheme altogether<br>which is not to say, that with a proper fix to the software or hardware, that the usb key is useless.</p></htmltext>
<tokenext>This is not to say that they broke the encryption , but just to say they figured out a way to bypass the encryption scheme altogetherwhich is not to say , that with a proper fix to the software or hardware , that the usb key is useless .</tokentext>
<sentencetext>This is not to say that they broke the encryption, but just to say they figured out a way to bypass the encryption scheme altogetherwhich is not to say, that with a proper fix to the software or hardware, that the usb key is useless.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659712</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262682660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Does anyone know what encryption they are using? Apparently the same stupid software is running on all the thumb drives. So either they're really all the same inside or they pirated from each other (I suspect the former).  I don't know if Truecrypt is something they might be using under the covers but that wouldn't surprise me either; they don't appear to have done much original work on the drives at all.</p></htmltext>
<tokenext>Does anyone know what encryption they are using ?
Apparently the same stupid software is running on all the thumb drives .
So either they 're really all the same inside or they pirated from each other ( I suspect the former ) .
I do n't know if Truecrypt is something they might be using under the covers but that would n't surprise me either ; they do n't appear to have done much original work on the drives at all .</tokentext>
<sentencetext>Does anyone know what encryption they are using?
Apparently the same stupid software is running on all the thumb drives.
So either they're really all the same inside or they pirated from each other (I suspect the former).
I don't know if Truecrypt is something they might be using under the covers but that wouldn't surprise me either; they don't appear to have done much original work on the drives at all.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659912</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262683620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>How much analysis has gone into attempting to break truecrypt?  Is there a backdoor?  Who wrote it, anyway; was it an individual or a government?</p></htmltext>
<tokenext>How much analysis has gone into attempting to break truecrypt ?
Is there a backdoor ?
Who wrote it , anyway ; was it an individual or a government ?</tokentext>
<sentencetext>How much analysis has gone into attempting to break truecrypt?
Is there a backdoor?
Who wrote it, anyway; was it an individual or a government?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658834</id>
	<title>Barack Obama lied</title>
	<author>Anonymous</author>
	<datestamp>1262721840000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>again!</p><p><a href="http://www.foxnews.com/politics/2010/01/05/c-span-challenges-congress-open-health-care-talks-tv-coverage/" title="foxnews.com" rel="nofollow">http://www.foxnews.com/politics/2010/01/05/c-span-challenges-congress-open-health-care-talks-tv-coverage/</a> [foxnews.com]</p></htmltext>
<tokenext>again ! http : //www.foxnews.com/politics/2010/01/05/c-span-challenges-congress-open-health-care-talks-tv-coverage/ [ foxnews.com ]</tokentext>
<sentencetext>again!http://www.foxnews.com/politics/2010/01/05/c-span-challenges-congress-open-health-care-talks-tv-coverage/ [foxnews.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659186</id>
	<title>Re:Who cares?</title>
	<author>Improv</author>
	<datestamp>1262723700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Some things really are like locking a house - windows passwords, normal unix passwords, etc. With those things, the user expects that someone has or can get access to things anyhow. However, there are many devices that are not so analogous - if there's sophisticated encryption in the hardware and they're selling it as a reasonably secure device, it's more like your neighbourhood bank, where you probably don't expect jane random to read a secret word on the internet to say to the guards that will have them open the vault.</p></htmltext>
<tokenext>Some things really are like locking a house - windows passwords , normal unix passwords , etc .
With those things , the user expects that someone has or can get access to things anyhow .
However , there are many devices that are not so analogous - if there 's sophisticated encryption in the hardware and they 're selling it as a reasonably secure device , it 's more like your neighbourhood bank , where you probably do n't expect jane random to read a secret word on the internet to say to the guards that will have them open the vault .</tokentext>
<sentencetext>Some things really are like locking a house - windows passwords, normal unix passwords, etc.
With those things, the user expects that someone has or can get access to things anyhow.
However, there are many devices that are not so analogous - if there's sophisticated encryption in the hardware and they're selling it as a reasonably secure device, it's more like your neighbourhood bank, where you probably don't expect jane random to read a secret word on the internet to say to the guards that will have them open the vault.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659298</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>JaWiB</author>
	<datestamp>1262724060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If they aren't encrypted, I assume that means that these devices don't actually meet the NIST standard. Couldn't there be a lawsuit for advertising the drives as such?</htmltext>
<tokenext>If they are n't encrypted , I assume that means that these devices do n't actually meet the NIST standard .
Could n't there be a lawsuit for advertising the drives as such ?</tokentext>
<sentencetext>If they aren't encrypted, I assume that means that these devices don't actually meet the NIST standard.
Couldn't there be a lawsuit for advertising the drives as such?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658532</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660176</id>
	<title>The result is inevitable...</title>
	<author>joocemann</author>
	<datestamp>1262684520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Once there has been established a perfect unbreakable encryption, they will then have to work on establishing perfect and unbreakable people that deal with the information; and that's much harder to do.</p><p>I think it is a smart move to keep putting up walls of security with encryption; people should try to maintain their secrecy for whatever purpose that is...  But history shows that the encryption will most likely be broken.  And given the day that the encryption cannot be broke, more focus will be applied to the human intelligence collection effort and the fallible characteristics of humans will then be the Achilles's heel (not that this approach isn't already well underway).</p></htmltext>
<tokenext>Once there has been established a perfect unbreakable encryption , they will then have to work on establishing perfect and unbreakable people that deal with the information ; and that 's much harder to do.I think it is a smart move to keep putting up walls of security with encryption ; people should try to maintain their secrecy for whatever purpose that is... But history shows that the encryption will most likely be broken .
And given the day that the encryption can not be broke , more focus will be applied to the human intelligence collection effort and the fallible characteristics of humans will then be the Achilles 's heel ( not that this approach is n't already well underway ) .</tokentext>
<sentencetext>Once there has been established a perfect unbreakable encryption, they will then have to work on establishing perfect and unbreakable people that deal with the information; and that's much harder to do.I think it is a smart move to keep putting up walls of security with encryption; people should try to maintain their secrecy for whatever purpose that is...  But history shows that the encryption will most likely be broken.
And given the day that the encryption cannot be broke, more focus will be applied to the human intelligence collection effort and the fallible characteristics of humans will then be the Achilles's heel (not that this approach isn't already well underway).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659126</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Anonymous</author>
	<datestamp>1262723400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>Can anyone explain to me why the disk manufacturers chose to reinvent the wheel,</p></div></blockquote><p>Because then it will be <i>their</i> wheel, which they do not need to pay a hefty(?) licence-fee for every created stick.</p><p>Also, companies in general do not make their product for <i>you</i> (who mistakingly thinks he can expect a decent product, working as advertised), but just as the twenty-eth century equivalent of the old beads and mirrors.  The cheaper they can produce their trinkets, the better.</p><p>Its your money they're after, and their product is just a means to the goal.</p><p>Hence laptops (even from well-known brands) with a failure-rate of over 40\% in the first year.<nobr> <wbr></nobr>:(</p></div>
	</htmltext>
<tokenext>Can anyone explain to me why the disk manufacturers chose to reinvent the wheel,Because then it will be their wheel , which they do not need to pay a hefty ( ?
) licence-fee for every created stick.Also , companies in general do not make their product for you ( who mistakingly thinks he can expect a decent product , working as advertised ) , but just as the twenty-eth century equivalent of the old beads and mirrors .
The cheaper they can produce their trinkets , the better.Its your money they 're after , and their product is just a means to the goal.Hence laptops ( even from well-known brands ) with a failure-rate of over 40 \ % in the first year .
: (</tokentext>
<sentencetext>Can anyone explain to me why the disk manufacturers chose to reinvent the wheel,Because then it will be their wheel, which they do not need to pay a hefty(?
) licence-fee for every created stick.Also, companies in general do not make their product for you (who mistakingly thinks he can expect a decent product, working as advertised), but just as the twenty-eth century equivalent of the old beads and mirrors.
The cheaper they can produce their trinkets, the better.Its your money they're after, and their product is just a means to the goal.Hence laptops (even from well-known brands) with a failure-rate of over 40\% in the first year.
:(
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760</id>
	<title>Re:Truecrypt</title>
	<author>Anonymous</author>
	<datestamp>1262721480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>What I got from the article was the following scenario:<br>1. Drive asks for a password<br>2. User enters a password<br>3a. The password is incorrect -&gt; "DO NOT OPEN" message is sent to the drive<br>3b. The password is correct -&gt; "OPEN" message is sent to the drive<br>4. User gains access to the drive</p><p>The "crackers" simply bypassed steps 1 and 2 and went straight to 3b. You'd of course have to be a complete idiot to design an authenticating mechanism in this manner. TrueCrypt does not share this design.</p></htmltext>
<tokenext>What I got from the article was the following scenario : 1 .
Drive asks for a password2 .
User enters a password3a .
The password is incorrect - &gt; " DO NOT OPEN " message is sent to the drive3b .
The password is correct - &gt; " OPEN " message is sent to the drive4 .
User gains access to the driveThe " crackers " simply bypassed steps 1 and 2 and went straight to 3b .
You 'd of course have to be a complete idiot to design an authenticating mechanism in this manner .
TrueCrypt does not share this design .</tokentext>
<sentencetext>What I got from the article was the following scenario:1.
Drive asks for a password2.
User enters a password3a.
The password is incorrect -&gt; "DO NOT OPEN" message is sent to the drive3b.
The password is correct -&gt; "OPEN" message is sent to the drive4.
User gains access to the driveThe "crackers" simply bypassed steps 1 and 2 and went straight to 3b.
You'd of course have to be a complete idiot to design an authenticating mechanism in this manner.
TrueCrypt does not share this design.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660708</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Andy Dodd</author>
	<datestamp>1262686320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Because then they wouldn't be able to charge double the price of a "normal" drive.</p></htmltext>
<tokenext>Because then they would n't be able to charge double the price of a " normal " drive .</tokentext>
<sentencetext>Because then they wouldn't be able to charge double the price of a "normal" drive.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660860</id>
	<title>Re:How does this differ from Truecrypt?</title>
	<author>Andy Dodd</author>
	<datestamp>1262686860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Also, these drives (in theory) force the user to encrypt the drive.  They can't accidentally forget to use TrueCrypt.</p><p>You can use a U3 drive to make a TrueCrypt drive that is nearly identical to these drives except:<br>1)  Aforementioned admin privs issues<br>2)  A user could just reformat the USB drive partition, making it a normal non-encrypted drive.</p></htmltext>
<tokenext>Also , these drives ( in theory ) force the user to encrypt the drive .
They ca n't accidentally forget to use TrueCrypt.You can use a U3 drive to make a TrueCrypt drive that is nearly identical to these drives except : 1 ) Aforementioned admin privs issues2 ) A user could just reformat the USB drive partition , making it a normal non-encrypted drive .</tokentext>
<sentencetext>Also, these drives (in theory) force the user to encrypt the drive.
They can't accidentally forget to use TrueCrypt.You can use a U3 drive to make a TrueCrypt drive that is nearly identical to these drives except:1)  Aforementioned admin privs issues2)  A user could just reformat the USB drive partition, making it a normal non-encrypted drive.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658742</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30688752
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665882
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659126
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660832
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658972
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659122
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659296
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658466
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660426
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662798
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659020
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658714
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30663506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30668904
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658532
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658834
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659408
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661658
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661352
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658804
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30667228
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659618
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658804
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30680608
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659712
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659722
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658466
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659360
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659912
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658772
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665788
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660360
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659186
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658660
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661014
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30678124
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660860
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658742
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658566
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30664726
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660360
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659752
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662612
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659298
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658532
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659344
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662100
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660708
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30664012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660924
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659020
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659056
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30680644
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665730
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660302
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_05_1734242_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660272
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659532
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658462
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660708
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659912
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658610
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658532
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659298
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658768
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659792
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658742
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660860
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659122
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659712
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659126
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658566
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658546
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658772
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659056
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659142
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662086
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30680608
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658602
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660426
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658804
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661352
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659618
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659198
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659774
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30678124
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30664012
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662612
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659872
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662100
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30680644
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662148
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661014
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658430
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30663506
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660388
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658834
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659020
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660924
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30662798
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658714
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658458
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658760
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659344
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659338
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659752
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665730
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658466
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659296
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659722
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660464
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658482
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659286
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659068
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660302
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659186
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659360
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658918
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658972
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659642
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660832
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30688752
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660272
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659408
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658504
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658718
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658830
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30661658
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30658660
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660360
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30664726
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665788
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30660828
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30668904
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30665882
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30667228
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_05_1734242.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_05_1734242.30659118
</commentlist>
</conversation>
