<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_05_27_131236</id>
	<title>Phony TCP Retransmissions Can Hide Secret Messages</title>
	<author>Soulskill</author>
	<datestamp>1243431660000</datestamp>
	<htmltext><a href="http://hughpickens.com/" rel="nofollow">Hugh Pickens</a> writes <i>"New Scientist reports that a team of steganographers at the Institute of Telecommunications in Warsaw, Poland have figured out how to send hidden messages <a href="http://www.newscientist.com/article/mg20227096.200-fake-web-traffic-can-hide-secret-chat.html">using the internet's transmission control protocol (TCP)</a> using a method that might help people in totalitarian regimes avoid censorship. Web, file transfer, email and peer-to-peer networks all use TCP, which ensures that data packets are received securely by making the sender wait until the receiver returns a 'got it' message. If no such acknowledgment arrives (on average 1 in 1000 packets gets lost or corrupted), the sender's computer sends the packet again in a system known as TCP's retransmission mechanism. The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when <a href="http://arxiv.org/pdf/0905.0363v3">email data packets are received successfully</a> (PDF). 'The receiver intentionally signals that a loss has occurred,' says Wojciech Mazurczyk. 'The sender then retransmits the packet but with some secret data inserted in it.' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message? As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG."</i></htmltext>
<tokenext>Hugh Pickens writes " New Scientist reports that a team of steganographers at the Institute of Telecommunications in Warsaw , Poland have figured out how to send hidden messages using the internet 's transmission control protocol ( TCP ) using a method that might help people in totalitarian regimes avoid censorship .
Web , file transfer , email and peer-to-peer networks all use TCP , which ensures that data packets are received securely by making the sender wait until the receiver returns a 'got it ' message .
If no such acknowledgment arrives ( on average 1 in 1000 packets gets lost or corrupted ) , the sender 's computer sends the packet again in a system known as TCP 's retransmission mechanism .
The new steganographic system , dubbed retransmission steganography ( RSTEG ) , relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully ( PDF ) .
'The receiver intentionally signals that a loss has occurred, ' says Wojciech Mazurczyk .
'The sender then retransmits the packet but with some secret data inserted in it .
' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message ?
As long as the system is not over-used , apparently not , because if a packet is corrupted , the original packet and the retransmitted one will differ from each other anyway , masking the use of RSTEG .
"</tokentext>
<sentencetext>Hugh Pickens writes "New Scientist reports that a team of steganographers at the Institute of Telecommunications in Warsaw, Poland have figured out how to send hidden messages using the internet's transmission control protocol (TCP) using a method that might help people in totalitarian regimes avoid censorship.
Web, file transfer, email and peer-to-peer networks all use TCP, which ensures that data packets are received securely by making the sender wait until the receiver returns a 'got it' message.
If no such acknowledgment arrives (on average 1 in 1000 packets gets lost or corrupted), the sender's computer sends the packet again in a system known as TCP's retransmission mechanism.
The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully (PDF).
'The receiver intentionally signals that a loss has occurred,' says Wojciech Mazurczyk.
'The sender then retransmits the packet but with some secret data inserted in it.
' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message?
As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109437</id>
	<title>Re:Might be a little obvious...</title>
	<author>Anonymous</author>
	<datestamp>1243438380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well the quote above is bollocks, isn't it.</p><p><i>if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG.</i></p><p>Except that the original and the retransmitted one will both have correct checksums, indicating unequivocally that something funny is going on.</p></div>
	</htmltext>
<tokenext>Well the quote above is bollocks , is n't it.if a packet is corrupted , the original packet and the retransmitted one will differ from each other anyway , masking the use of RSTEG.Except that the original and the retransmitted one will both have correct checksums , indicating unequivocally that something funny is going on .</tokentext>
<sentencetext>Well the quote above is bollocks, isn't it.if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG.Except that the original and the retransmitted one will both have correct checksums, indicating unequivocally that something funny is going on.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811</id>
	<title>Does it matter which data you send first?</title>
	<author>drinkypoo</author>
	<datestamp>1243435380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Does it matter if you send the real data or the masking data first, if you're just going to "fail" it and resend with the other data?</p></htmltext>
<tokenext>Does it matter if you send the real data or the masking data first , if you 're just going to " fail " it and resend with the other data ?</tokentext>
<sentencetext>Does it matter if you send the real data or the masking data first, if you're just going to "fail" it and resend with the other data?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110693</id>
	<title>Or even just count the retransmits?</title>
	<author>davidwr</author>
	<datestamp>1243443540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Even simpler, but more overhead:</p><p>Every few minutes stop sending fake retransmits.  This gives you an approximate real noise level.<br>In the in-between times, send a lot of retransmits for a "1" and a few for a "0."<br>Encode your message so it's tolerant of multi-bit errors.</p><p>You should be able to get a few dozen bits per hour out of this scheme easily, without deliberately making bad packets.  That's enough to say "We attack at dawn."</p></htmltext>
<tokenext>Even simpler , but more overhead : Every few minutes stop sending fake retransmits .
This gives you an approximate real noise level.In the in-between times , send a lot of retransmits for a " 1 " and a few for a " 0 .
" Encode your message so it 's tolerant of multi-bit errors.You should be able to get a few dozen bits per hour out of this scheme easily , without deliberately making bad packets .
That 's enough to say " We attack at dawn .
"</tokentext>
<sentencetext>Even simpler, but more overhead:Every few minutes stop sending fake retransmits.
This gives you an approximate real noise level.In the in-between times, send a lot of retransmits for a "1" and a few for a "0.
"Encode your message so it's tolerant of multi-bit errors.You should be able to get a few dozen bits per hour out of this scheme easily, without deliberately making bad packets.
That's enough to say "We attack at dawn.
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108855</id>
	<title>Real errors?</title>
	<author>PhireN</author>
	<datestamp>1243435620000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext>What happens when one of the packets actually gets corrupted?</htmltext>
<tokenext>What happens when one of the packets actually gets corrupted ?</tokentext>
<sentencetext>What happens when one of the packets actually gets corrupted?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110191</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>Anonymous</author>
	<datestamp>1243441620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.</p></div><p>What would that be in terms of a car analogy ?</p></div>
	</htmltext>
<tokenext>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss ( white noise ) at high volume.What would that be in terms of a car analogy ?</tokentext>
<sentencetext>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.What would that be in terms of a car analogy ?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110295</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243442040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well in my jurisdiction, one basic rule of legal encryption is that the secret keys are known by the govt so that's fatally flawed too. Steganography is just another part of the security onion.</p></htmltext>
<tokenext>Well in my jurisdiction , one basic rule of legal encryption is that the secret keys are known by the govt so that 's fatally flawed too .
Steganography is just another part of the security onion .</tokentext>
<sentencetext>Well in my jurisdiction, one basic rule of legal encryption is that the secret keys are known by the govt so that's fatally flawed too.
Steganography is just another part of the security onion.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109137</id>
	<title>Re:Why send diffrent packages?</title>
	<author>ShadowRangerRIT</author>
	<datestamp>1243436940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>TCP/IP protocol overhead: 160 bits/packet (TCP) + 160 bits/packet (IPv4) = 320 bits/packet (assuming no data, and that might look a little suspicious)</p><p>320 bits/packet * 250 packets/real bit = 80,000 bits/real bit</p><p>80,000 bits/real bit * 700 MB (smallest common size of compressed movie) = 80,000 bits/real bit * 5,872,025,600 real bits = 469,762,048,000,000 bits transmitted, or 53.4 TB.</p><p>Congratulations: Assuming you use the absurdly noticeable "empty packet" strategy, on a 20 megabit line with no other overhead, you could transmit one whole movie in "only" 272 days.  No one will notice the absurd amount of empty traffic in that entire time I'm sure.</p></htmltext>
<tokenext>TCP/IP protocol overhead : 160 bits/packet ( TCP ) + 160 bits/packet ( IPv4 ) = 320 bits/packet ( assuming no data , and that might look a little suspicious ) 320 bits/packet * 250 packets/real bit = 80,000 bits/real bit80,000 bits/real bit * 700 MB ( smallest common size of compressed movie ) = 80,000 bits/real bit * 5,872,025,600 real bits = 469,762,048,000,000 bits transmitted , or 53.4 TB.Congratulations : Assuming you use the absurdly noticeable " empty packet " strategy , on a 20 megabit line with no other overhead , you could transmit one whole movie in " only " 272 days .
No one will notice the absurd amount of empty traffic in that entire time I 'm sure .</tokentext>
<sentencetext>TCP/IP protocol overhead: 160 bits/packet (TCP) + 160 bits/packet (IPv4) = 320 bits/packet (assuming no data, and that might look a little suspicious)320 bits/packet * 250 packets/real bit = 80,000 bits/real bit80,000 bits/real bit * 700 MB (smallest common size of compressed movie) = 80,000 bits/real bit * 5,872,025,600 real bits = 469,762,048,000,000 bits transmitted, or 53.4 TB.Congratulations: Assuming you use the absurdly noticeable "empty packet" strategy, on a 20 megabit line with no other overhead, you could transmit one whole movie in "only" 272 days.
No one will notice the absurd amount of empty traffic in that entire time I'm sure.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108885</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110473</id>
	<title>Sure</title>
	<author>Rene S. Hollan</author>
	<datestamp>1243442760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There is a principle that if there is any means of systems affecting each other, that mechanism can be used to communicate.</p><p>Consider classified and unclassified processes in a "secure" operating system, separated by a process boundary, and disjoint credentials (so, they can't see the same resources, like files).</p><p>The can communicate because the system has a finite amount of memory and simply requesting memory resources and noting successes and failures can be used to communicate.</p><p>It's awfully inefficient, but it can be done.</p></htmltext>
<tokenext>There is a principle that if there is any means of systems affecting each other , that mechanism can be used to communicate.Consider classified and unclassified processes in a " secure " operating system , separated by a process boundary , and disjoint credentials ( so , they ca n't see the same resources , like files ) .The can communicate because the system has a finite amount of memory and simply requesting memory resources and noting successes and failures can be used to communicate.It 's awfully inefficient , but it can be done .</tokentext>
<sentencetext>There is a principle that if there is any means of systems affecting each other, that mechanism can be used to communicate.Consider classified and unclassified processes in a "secure" operating system, separated by a process boundary, and disjoint credentials (so, they can't see the same resources, like files).The can communicate because the system has a finite amount of memory and simply requesting memory resources and noting successes and failures can be used to communicate.It's awfully inefficient, but it can be done.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110217</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243441680000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>You miss the point of steganography. Encryption assumes that it's acceptable for an attacker to know there's a communications channel, the requirement is to keep the attacker from finding out the contents of the channel. Steganography is intended to conceal the very existence of the communications channel from a potential attacker.</p><p>Consider the situation a dissident in China might be in. Merely concealing what he's posting won't help him. The government doesn't care what the content is, the mere fact that he's hiding it from them's enough to convict him as far as they're concerned. For him encryption isn't required, an encrypted message the government can't read is just as damning as the plaintext would be. What he needs is a channel that's so unobtrusive that the government doesn't realize he's posting anything at all. And if the government doesn't realize there's a message there, they aren't even going to try to read it.</p></htmltext>
<tokenext>You miss the point of steganography .
Encryption assumes that it 's acceptable for an attacker to know there 's a communications channel , the requirement is to keep the attacker from finding out the contents of the channel .
Steganography is intended to conceal the very existence of the communications channel from a potential attacker.Consider the situation a dissident in China might be in .
Merely concealing what he 's posting wo n't help him .
The government does n't care what the content is , the mere fact that he 's hiding it from them 's enough to convict him as far as they 're concerned .
For him encryption is n't required , an encrypted message the government ca n't read is just as damning as the plaintext would be .
What he needs is a channel that 's so unobtrusive that the government does n't realize he 's posting anything at all .
And if the government does n't realize there 's a message there , they are n't even going to try to read it .</tokentext>
<sentencetext>You miss the point of steganography.
Encryption assumes that it's acceptable for an attacker to know there's a communications channel, the requirement is to keep the attacker from finding out the contents of the channel.
Steganography is intended to conceal the very existence of the communications channel from a potential attacker.Consider the situation a dissident in China might be in.
Merely concealing what he's posting won't help him.
The government doesn't care what the content is, the mere fact that he's hiding it from them's enough to convict him as far as they're concerned.
For him encryption isn't required, an encrypted message the government can't read is just as damning as the plaintext would be.
What he needs is a channel that's so unobtrusive that the government doesn't realize he's posting anything at all.
And if the government doesn't realize there's a message there, they aren't even going to try to read it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109119</id>
	<title>Even 1 bit per 1 megabyte might be a problem</title>
	<author>Anonymous</author>
	<datestamp>1243436880000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>With the packet size of ~1500 bytes a 1MB send means ~700 packets. With an average of 0.1\% packets lost even sending a single bit of information (a single 0 or 1) per 1MB transfered gives you a 150\% increase in lost packets<br>With dialup and it's default packet size of ~500 bytes combined with much higher packet loss you might be able to sneak in 1-2 bytes per MB without making it possible at all to detect. Considering 56kbps modem upload speed and need for some error/fault correction in the protocol sending an equivalent of SMS (160 characters) would take more than 2 days.</p><p>All that is assuming that someone is looking for that type of transmissions. If not it looks like a very nice method to send very short messages.</p></htmltext>
<tokenext>With the packet size of ~ 1500 bytes a 1MB send means ~ 700 packets .
With an average of 0.1 \ % packets lost even sending a single bit of information ( a single 0 or 1 ) per 1MB transfered gives you a 150 \ % increase in lost packetsWith dialup and it 's default packet size of ~ 500 bytes combined with much higher packet loss you might be able to sneak in 1-2 bytes per MB without making it possible at all to detect .
Considering 56kbps modem upload speed and need for some error/fault correction in the protocol sending an equivalent of SMS ( 160 characters ) would take more than 2 days.All that is assuming that someone is looking for that type of transmissions .
If not it looks like a very nice method to send very short messages .</tokentext>
<sentencetext>With the packet size of ~1500 bytes a 1MB send means ~700 packets.
With an average of 0.1\% packets lost even sending a single bit of information (a single 0 or 1) per 1MB transfered gives you a 150\% increase in lost packetsWith dialup and it's default packet size of ~500 bytes combined with much higher packet loss you might be able to sneak in 1-2 bytes per MB without making it possible at all to detect.
Considering 56kbps modem upload speed and need for some error/fault correction in the protocol sending an equivalent of SMS (160 characters) would take more than 2 days.All that is assuming that someone is looking for that type of transmissions.
If not it looks like a very nice method to send very short messages.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109561</id>
	<title>Poles did it again -- Enigma 2.0</title>
	<author>enterix</author>
	<datestamp>1243438920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Last century <a href="http://en.wikipedia.org/wiki/Biuro\_Szyfr\%C3\%B3w" title="wikipedia.org" rel="nofollow">Poles cracked Enigma</a> [wikipedia.org]</p><p>Now TCP...</p></htmltext>
<tokenext>Last century Poles cracked Enigma [ wikipedia.org ] Now TCP.. .</tokentext>
<sentencetext>Last century Poles cracked Enigma [wikipedia.org]Now TCP...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109367</id>
	<title>Zero chance</title>
	<author>Anonymous</author>
	<datestamp>1243438080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Too late. Packet scanners have been examining that since at least 2002. I know, since I wrote one for sale to various TL Agencies.</htmltext>
<tokenext>Too late .
Packet scanners have been examining that since at least 2002 .
I know , since I wrote one for sale to various TL Agencies .</tokentext>
<sentencetext>Too late.
Packet scanners have been examining that since at least 2002.
I know, since I wrote one for sale to various TL Agencies.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108985</id>
	<title>Re:Might be a little obvious...</title>
	<author>wjh31</author>
	<datestamp>1243436160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>no, because you can simulate the normal faliure rate, and so send 1kB of steganographised data per 1MB of real data (on average). While this isnt a particularly high rate, it means that you can send a few kB of text to your friend when it seems you are just sending some photos of your holiday/party/whatever. A few kB of text sounds like a pretty reasonable amound of information to be sending, especially if compressed first.</htmltext>
<tokenext>no , because you can simulate the normal faliure rate , and so send 1kB of steganographised data per 1MB of real data ( on average ) .
While this isnt a particularly high rate , it means that you can send a few kB of text to your friend when it seems you are just sending some photos of your holiday/party/whatever .
A few kB of text sounds like a pretty reasonable amound of information to be sending , especially if compressed first .</tokentext>
<sentencetext>no, because you can simulate the normal faliure rate, and so send 1kB of steganographised data per 1MB of real data (on average).
While this isnt a particularly high rate, it means that you can send a few kB of text to your friend when it seems you are just sending some photos of your holiday/party/whatever.
A few kB of text sounds like a pretty reasonable amound of information to be sending, especially if compressed first.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28115697</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>Anonymous</author>
	<datestamp>1243420800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Double up - it's a diff</p></htmltext>
<tokenext>Double up - it 's a diff</tokentext>
<sentencetext>Double up - it's a diff</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109775</id>
	<title>hi</title>
	<author>Anonymous</author>
	<datestamp>1243439940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>might help people in totalitarian regimes avoid censorship</p></div><p>I'm assuming this includes the United States;)</p></div>
	</htmltext>
<tokenext>might help people in totalitarian regimes avoid censorshipI 'm assuming this includes the United States ; )</tokentext>
<sentencetext>might help people in totalitarian regimes avoid censorshipI'm assuming this includes the United States;)
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112641</id>
	<title>Pointless</title>
	<author>Anonymous</author>
	<datestamp>1243451040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not only do they seemingly not understand cryptography, stenography, or data tracking, they do not understand how much of Asia's network will not let this pass even as it stands now. There is a lot of Asia that runs through SAT links and they use true TCP acceleration which proxies the TCP segments. The retransmission will be pointless here at best. At worst they will screw up the far side connection resulting in a RST.</p><p>Also it would be like a little red flag saying "Look at me!" every time it was used. With data tracking equipment that stores terabytes of data for post analysis, it is almost assured to raise some questions. I can only assume that's not the effect they are looking for.</p><p>They set out to find a weakness in TCP and only found weakness in themselves. I recommend they pool their resources and buy a cheap book on stenography. Or use encryption.</p><p>
&nbsp;</p></htmltext>
<tokenext>Not only do they seemingly not understand cryptography , stenography , or data tracking , they do not understand how much of Asia 's network will not let this pass even as it stands now .
There is a lot of Asia that runs through SAT links and they use true TCP acceleration which proxies the TCP segments .
The retransmission will be pointless here at best .
At worst they will screw up the far side connection resulting in a RST.Also it would be like a little red flag saying " Look at me !
" every time it was used .
With data tracking equipment that stores terabytes of data for post analysis , it is almost assured to raise some questions .
I can only assume that 's not the effect they are looking for.They set out to find a weakness in TCP and only found weakness in themselves .
I recommend they pool their resources and buy a cheap book on stenography .
Or use encryption .
 </tokentext>
<sentencetext>Not only do they seemingly not understand cryptography, stenography, or data tracking, they do not understand how much of Asia's network will not let this pass even as it stands now.
There is a lot of Asia that runs through SAT links and they use true TCP acceleration which proxies the TCP segments.
The retransmission will be pointless here at best.
At worst they will screw up the far side connection resulting in a RST.Also it would be like a little red flag saying "Look at me!
" every time it was used.
With data tracking equipment that stores terabytes of data for post analysis, it is almost assured to raise some questions.
I can only assume that's not the effect they are looking for.They set out to find a weakness in TCP and only found weakness in themselves.
I recommend they pool their resources and buy a cheap book on stenography.
Or use encryption.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111415</id>
	<title>OK if you're not already being watched</title>
	<author>Anonymous</author>
	<datestamp>1243446300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>but if they already suspect you, all they have to do is watch your stream and see which retransmit requests correspond to a packet with a perfectly good checksum.  Given the<nobr> <wbr></nobr>.1\% error rate quoted, the odds of a false positive are only 1/1 000 000</p></htmltext>
<tokenext>but if they already suspect you , all they have to do is watch your stream and see which retransmit requests correspond to a packet with a perfectly good checksum .
Given the .1 \ % error rate quoted , the odds of a false positive are only 1/1 000 000</tokentext>
<sentencetext>but if they already suspect you, all they have to do is watch your stream and see which retransmit requests correspond to a packet with a perfectly good checksum.
Given the .1\% error rate quoted, the odds of a false positive are only 1/1 000 000</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110065</id>
	<title>How common are re-transmits due to corruption?</title>
	<author>bmajik</author>
	<datestamp>1243441080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>These days, physical link layers seem to be pretty stinking good.  How common are TCP retransmits for reasons of corruption?</p><p>Why do this at the TCP layer?  Why not the application layer?  Consider all of the covert channels that might exist with the ability of POST, PUT, and even method=GET.</p><p>I've thought off and on about botnets that use spamblogs or google search + zeitgeist queries to coordinate their activities.  The web is the largest visible surface area of the internet, so if I wanted to hide something in plain sight, that's one avenue to look into.</p></htmltext>
<tokenext>These days , physical link layers seem to be pretty stinking good .
How common are TCP retransmits for reasons of corruption ? Why do this at the TCP layer ?
Why not the application layer ?
Consider all of the covert channels that might exist with the ability of POST , PUT , and even method = GET.I 've thought off and on about botnets that use spamblogs or google search + zeitgeist queries to coordinate their activities .
The web is the largest visible surface area of the internet , so if I wanted to hide something in plain sight , that 's one avenue to look into .</tokentext>
<sentencetext>These days, physical link layers seem to be pretty stinking good.
How common are TCP retransmits for reasons of corruption?Why do this at the TCP layer?
Why not the application layer?
Consider all of the covert channels that might exist with the ability of POST, PUT, and even method=GET.I've thought off and on about botnets that use spamblogs or google search + zeitgeist queries to coordinate their activities.
The web is the largest visible surface area of the internet, so if I wanted to hide something in plain sight, that's one avenue to look into.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110575</id>
	<title>Nope.  No one has thought of this yet.  Yarly.</title>
	<author>Twyst3d</author>
	<datestamp>1243443060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sorry but these people werent the first to think of this.  Only the first to publicly announce they had.

I mean really.  I never tried but I had this idea in the late 90s.  Others probably thought it up before even I conceived of it.

Then again, the layers was probably the biggest snoozefest I ever had to sleep through in class.  So maybe it took so long because people kept falling asleep while trying to do it.

Oh well better find me a copy of netmon and start sniffin.</htmltext>
<tokenext>Sorry but these people werent the first to think of this .
Only the first to publicly announce they had .
I mean really .
I never tried but I had this idea in the late 90s .
Others probably thought it up before even I conceived of it .
Then again , the layers was probably the biggest snoozefest I ever had to sleep through in class .
So maybe it took so long because people kept falling asleep while trying to do it .
Oh well better find me a copy of netmon and start sniffin .</tokentext>
<sentencetext>Sorry but these people werent the first to think of this.
Only the first to publicly announce they had.
I mean really.
I never tried but I had this idea in the late 90s.
Others probably thought it up before even I conceived of it.
Then again, the layers was probably the biggest snoozefest I ever had to sleep through in class.
So maybe it took so long because people kept falling asleep while trying to do it.
Oh well better find me a copy of netmon and start sniffin.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108929</id>
	<title>Re:Might be a little obvious...</title>
	<author>Anonymous</author>
	<datestamp>1243435920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?</p></div><p>
Sigh....at least read TFS?!?</p><p><div class="quote"><p>As long as the system is not over-used</p></div><p>
In other words, this falls in the category of "probably not practical, but it can be done and its pretty nifty." If they didn't invent it, someone else would have, and not too many other people would give a damn. I doubt that it's of interest to crypto-geeks either, since it's so easily detected and just steganography at the end of the day.</p></div>
	</htmltext>
<tokenext>Does n't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets ?
And , would your bandwidth not also double , if you use this and re-send one secret packet for every 'normal ' packet ?
Sigh....at least read TFS ? !
? As long as the system is not over-used In other words , this falls in the category of " probably not practical , but it can be done and its pretty nifty .
" If they did n't invent it , someone else would have , and not too many other people would give a damn .
I doubt that it 's of interest to crypto-geeks either , since it 's so easily detected and just steganography at the end of the day .</tokentext>
<sentencetext>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?
Sigh....at least read TFS?!
?As long as the system is not over-used
In other words, this falls in the category of "probably not practical, but it can be done and its pretty nifty.
" If they didn't invent it, someone else would have, and not too many other people would give a damn.
I doubt that it's of interest to crypto-geeks either, since it's so easily detected and just steganography at the end of the day.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113261</id>
	<title>Re:lost vs corrupted</title>
	<author>againjj</author>
	<datestamp>1243453560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You can't double send without acknowledgment for each send.  This is because you can not know if the receiving end received both packets, since packets get arbitrarily dropped during intermediate hops.</htmltext>
<tokenext>You ca n't double send without acknowledgment for each send .
This is because you can not know if the receiving end received both packets , since packets get arbitrarily dropped during intermediate hops .</tokentext>
<sentencetext>You can't double send without acknowledgment for each send.
This is because you can not know if the receiving end received both packets, since packets get arbitrarily dropped during intermediate hops.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109003</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</id>
	<title>A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243439160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Heh, I can think up a half dozen better stegas:</p><p>(1) Encode the data as the packet length.<br>(2) Encode the data as the packet checksum<br>(3) Encode the data as the fragment offset.<br>(4) Encode the data as the number of extra ACKS.<br>(5) Encode the data as the starting connection sequence number.<br>(6) Encode the data as the window size.<br>(7) Encode the data as the inter-packet delay.</p><p>Steganography has the fatal flaw that the method has to remain secret.  One basic rule of encryption is to assume the method is discernible and<br>the security must be all in some secret key.</p></htmltext>
<tokenext>Heh , I can think up a half dozen better stegas : ( 1 ) Encode the data as the packet length .
( 2 ) Encode the data as the packet checksum ( 3 ) Encode the data as the fragment offset .
( 4 ) Encode the data as the number of extra ACKS .
( 5 ) Encode the data as the starting connection sequence number .
( 6 ) Encode the data as the window size .
( 7 ) Encode the data as the inter-packet delay.Steganography has the fatal flaw that the method has to remain secret .
One basic rule of encryption is to assume the method is discernible andthe security must be all in some secret key .</tokentext>
<sentencetext>Heh, I can think up a half dozen better stegas:(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.Steganography has the fatal flaw that the method has to remain secret.
One basic rule of encryption is to assume the method is discernible andthe security must be all in some secret key.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111081</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243445100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Which of those can you change without breaking normal TCP functionality?  And which of those is normally changed repeatedly as part of a conversation?</p></htmltext>
<tokenext>Which of those can you change without breaking normal TCP functionality ?
And which of those is normally changed repeatedly as part of a conversation ?</tokentext>
<sentencetext>Which of those can you change without breaking normal TCP functionality?
And which of those is normally changed repeatedly as part of a conversation?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108877</id>
	<title>torrents</title>
	<author>Anonymous</author>
	<datestamp>1243435680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>can this somehow be used to bypass Microsoft's ISA proxy and run torrents through it when p2p is blocked??</p></htmltext>
<tokenext>can this somehow be used to bypass Microsoft 's ISA proxy and run torrents through it when p2p is blocked ?
?</tokentext>
<sentencetext>can this somehow be used to bypass Microsoft's ISA proxy and run torrents through it when p2p is blocked?
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110513</id>
	<title>Wow, it's a good thing...</title>
	<author>Ezekiel68</author>
	<datestamp>1243442880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>...the censors in totalitarian regimes don't keep up with these kinds of developments.<p>Oh, wait...</p></htmltext>
<tokenext>...the censors in totalitarian regimes do n't keep up with these kinds of developments.Oh , wait.. .</tokentext>
<sentencetext>...the censors in totalitarian regimes don't keep up with these kinds of developments.Oh, wait...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110677</id>
	<title>over-used</title>
	<author>Anonymous</author>
	<datestamp>1243443540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt;As long as the system is not over-used</p><p>This assumption only works if nobody uses it. If it's really useful, over-use is inevitable.</p></htmltext>
<tokenext>&gt; As long as the system is not over-usedThis assumption only works if nobody uses it .
If it 's really useful , over-use is inevitable .</tokentext>
<sentencetext>&gt;As long as the system is not over-usedThis assumption only works if nobody uses it.
If it's really useful, over-use is inevitable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109739</id>
	<title>Seems detectable...</title>
	<author>Anonymous</author>
	<datestamp>1243439700000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>-----"The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully (PDF). 'The sender then retransmits the packet but with some secret data inserted in it.' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message? As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG."------<br><br>Ok so we're re-tran'ing on packets we claim to be corrupt, but that were received successfully.  So by monitoring traffic and keeping careful note of which packet the retransmit is requested on, and seeing what the checksum of that packet was, we will know whether an anomalous request is being sent.  Basically the checksum of an uncorrupted packet will be correct, so while not a conclusive test, it's a tip off that something is up (either malicious intent, or a network problem downstream between the monitor and the receiving host causing corruption).  Some analysis can also be done at this point to compare the frequency of these with run of the mill retransmits and possibly detect odd behavior.  Yes it will be mixed in with noise, but I think with some careful observation a pattern could be recognized.<br><br>Some other ways off the top of my head to go about this:<br>- Remote host intentionally sends a corrupt packet in response first, which is actually some creatively XOR'd version of what was expected but intended to look like typical upstream nonsense.  The retransmit, which is now keyed off an actual corrupt packet, sends what should be there.  The receiver can then combine the two into a meaningful secret message, while not actually sending retransmit req's for properly assembled packets.  IMO this is only really detectable by abnormally high levels of retrans, or something which knows the trick and proactively tries to reassemble the information.  Encrypt it and likely it will never appear as anything more than line garbage.<br>- Since the only thing that must remain constant is the destination (or does it?), why not distribute this.  Set it up using a botnet, and since these are very small messages now being spread out across a hundred hosts (or more), the requirements to monitor and detect traffic and then correlate it go up significantly.  Will a single slightly "off" packet from a host trigger an alarm?  Probably not.  Spread out the signal distribution over a bunch of servers to receive the traffic as well and it will probably never be noticed.</htmltext>
<tokenext>----- " The new steganographic system , dubbed retransmission steganography ( RSTEG ) , relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully ( PDF ) .
'The sender then retransmits the packet but with some secret data inserted in it .
' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message ?
As long as the system is not over-used , apparently not , because if a packet is corrupted , the original packet and the retransmitted one will differ from each other anyway , masking the use of RSTEG .
" ------Ok so we 're re-tran'ing on packets we claim to be corrupt , but that were received successfully .
So by monitoring traffic and keeping careful note of which packet the retransmit is requested on , and seeing what the checksum of that packet was , we will know whether an anomalous request is being sent .
Basically the checksum of an uncorrupted packet will be correct , so while not a conclusive test , it 's a tip off that something is up ( either malicious intent , or a network problem downstream between the monitor and the receiving host causing corruption ) .
Some analysis can also be done at this point to compare the frequency of these with run of the mill retransmits and possibly detect odd behavior .
Yes it will be mixed in with noise , but I think with some careful observation a pattern could be recognized.Some other ways off the top of my head to go about this : - Remote host intentionally sends a corrupt packet in response first , which is actually some creatively XOR 'd version of what was expected but intended to look like typical upstream nonsense .
The retransmit , which is now keyed off an actual corrupt packet , sends what should be there .
The receiver can then combine the two into a meaningful secret message , while not actually sending retransmit req 's for properly assembled packets .
IMO this is only really detectable by abnormally high levels of retrans , or something which knows the trick and proactively tries to reassemble the information .
Encrypt it and likely it will never appear as anything more than line garbage.- Since the only thing that must remain constant is the destination ( or does it ?
) , why not distribute this .
Set it up using a botnet , and since these are very small messages now being spread out across a hundred hosts ( or more ) , the requirements to monitor and detect traffic and then correlate it go up significantly .
Will a single slightly " off " packet from a host trigger an alarm ?
Probably not .
Spread out the signal distribution over a bunch of servers to receive the traffic as well and it will probably never be noticed .</tokentext>
<sentencetext>-----"The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully (PDF).
'The sender then retransmits the packet but with some secret data inserted in it.
' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message?
As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG.
"------Ok so we're re-tran'ing on packets we claim to be corrupt, but that were received successfully.
So by monitoring traffic and keeping careful note of which packet the retransmit is requested on, and seeing what the checksum of that packet was, we will know whether an anomalous request is being sent.
Basically the checksum of an uncorrupted packet will be correct, so while not a conclusive test, it's a tip off that something is up (either malicious intent, or a network problem downstream between the monitor and the receiving host causing corruption).
Some analysis can also be done at this point to compare the frequency of these with run of the mill retransmits and possibly detect odd behavior.
Yes it will be mixed in with noise, but I think with some careful observation a pattern could be recognized.Some other ways off the top of my head to go about this:- Remote host intentionally sends a corrupt packet in response first, which is actually some creatively XOR'd version of what was expected but intended to look like typical upstream nonsense.
The retransmit, which is now keyed off an actual corrupt packet, sends what should be there.
The receiver can then combine the two into a meaningful secret message, while not actually sending retransmit req's for properly assembled packets.
IMO this is only really detectable by abnormally high levels of retrans, or something which knows the trick and proactively tries to reassemble the information.
Encrypt it and likely it will never appear as anything more than line garbage.- Since the only thing that must remain constant is the destination (or does it?
), why not distribute this.
Set it up using a botnet, and since these are very small messages now being spread out across a hundred hosts (or more), the requirements to monitor and detect traffic and then correlate it go up significantly.
Will a single slightly "off" packet from a host trigger an alarm?
Probably not.
Spread out the signal distribution over a bunch of servers to receive the traffic as well and it will probably never be noticed.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113859</id>
	<title>Wow</title>
	<author>Akita24</author>
	<datestamp>1243456260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I thought Windows 7 wasn't going to be released until the end of the year.</htmltext>
<tokenext>I thought Windows 7 was n't going to be released until the end of the year .</tokentext>
<sentencetext>I thought Windows 7 wasn't going to be released until the end of the year.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109565</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>drinkypoo</author>
	<datestamp>1243438980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.</p></div><p>Well, no, it don't be like that mon, because the communications are digital in nature and sent over an unsecured network. It be easy to subject them to pattern analysis when you don't have to do any A to D don't ya know.</p></div>
	</htmltext>
<tokenext>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss ( white noise ) at high volume.Well , no , it do n't be like that mon , because the communications are digital in nature and sent over an unsecured network .
It be easy to subject them to pattern analysis when you do n't have to do any A to D do n't ya know .</tokentext>
<sentencetext>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.Well, no, it don't be like that mon, because the communications are digital in nature and sent over an unsecured network.
It be easy to subject them to pattern analysis when you don't have to do any A to D don't ya know.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109283</id>
	<title>Better if roles are reversed</title>
	<author>Anonymous</author>
	<datestamp>1243437540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is definitely a cool idea, but is readily detectable as others have already pointed out because the transmitted and retransmitted packets will obviously differ, and it is easy for someone to detect such a transmission and recover the steganographic message.</p><p>But, if you reverse the roles of sender and receiver, a much harder to detect mechanism can be embedded in the occurrence of each retransmission request.  In the simplest scheme (which is easily detectable, so I would not recommend it), Alice wants to send a message to Bob.  So, through a pre-arranged mechanism, Bob starts sending Alice a file.  As each packet arrives, if Alice sends and ACK, she is sending Bob a 1, if Alice sends a re-transmission request, she is sending Bob a 0.  The file being transmitted is acting as a carrier and has nothing to do with the steganographic message, which is encoded in the sequence of ACK / retransmit replies.  To make this scheme less easily detectable, most packets will have to be handled normally (not encoding a reverse flow message), and only a relative few will be used to encode steganographic bits.  And since TCP/IP is lossy, multi-failure CRC will have to be layered on top.</p></htmltext>
<tokenext>This is definitely a cool idea , but is readily detectable as others have already pointed out because the transmitted and retransmitted packets will obviously differ , and it is easy for someone to detect such a transmission and recover the steganographic message.But , if you reverse the roles of sender and receiver , a much harder to detect mechanism can be embedded in the occurrence of each retransmission request .
In the simplest scheme ( which is easily detectable , so I would not recommend it ) , Alice wants to send a message to Bob .
So , through a pre-arranged mechanism , Bob starts sending Alice a file .
As each packet arrives , if Alice sends and ACK , she is sending Bob a 1 , if Alice sends a re-transmission request , she is sending Bob a 0 .
The file being transmitted is acting as a carrier and has nothing to do with the steganographic message , which is encoded in the sequence of ACK / retransmit replies .
To make this scheme less easily detectable , most packets will have to be handled normally ( not encoding a reverse flow message ) , and only a relative few will be used to encode steganographic bits .
And since TCP/IP is lossy , multi-failure CRC will have to be layered on top .</tokentext>
<sentencetext>This is definitely a cool idea, but is readily detectable as others have already pointed out because the transmitted and retransmitted packets will obviously differ, and it is easy for someone to detect such a transmission and recover the steganographic message.But, if you reverse the roles of sender and receiver, a much harder to detect mechanism can be embedded in the occurrence of each retransmission request.
In the simplest scheme (which is easily detectable, so I would not recommend it), Alice wants to send a message to Bob.
So, through a pre-arranged mechanism, Bob starts sending Alice a file.
As each packet arrives, if Alice sends and ACK, she is sending Bob a 1, if Alice sends a re-transmission request, she is sending Bob a 0.
The file being transmitted is acting as a carrier and has nothing to do with the steganographic message, which is encoded in the sequence of ACK / retransmit replies.
To make this scheme less easily detectable, most packets will have to be handled normally (not encoding a reverse flow message), and only a relative few will be used to encode steganographic bits.
And since TCP/IP is lossy, multi-failure CRC will have to be layered on top.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111445</id>
	<title>The secrecy isn't a bug...</title>
	<author>sean.peters</author>
	<datestamp>1243446360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Steganography has the fatal flaw that the method has to remain secret. One basic rule of encryption is to assume the method is discernible and
the security must be all in some secret key.</p></div></blockquote><p>Secrecy isn't a bug, it's a feature. For the target audience, if you get caught sending out encrypted messages, you immediately become a suspect. Which, in turn, can lead to a pleasant stay in the local version of Guantanamo until you decide to cough up the key. The object of the game is to prevent the authorities from knowing you've even sent a message. That's the whole point of steganography - if there was no need to hide the fact that a message existed, you wouldn't need steganography at all. </p></div>
	</htmltext>
<tokenext>Steganography has the fatal flaw that the method has to remain secret .
One basic rule of encryption is to assume the method is discernible and the security must be all in some secret key.Secrecy is n't a bug , it 's a feature .
For the target audience , if you get caught sending out encrypted messages , you immediately become a suspect .
Which , in turn , can lead to a pleasant stay in the local version of Guantanamo until you decide to cough up the key .
The object of the game is to prevent the authorities from knowing you 've even sent a message .
That 's the whole point of steganography - if there was no need to hide the fact that a message existed , you would n't need steganography at all .</tokentext>
<sentencetext>Steganography has the fatal flaw that the method has to remain secret.
One basic rule of encryption is to assume the method is discernible and
the security must be all in some secret key.Secrecy isn't a bug, it's a feature.
For the target audience, if you get caught sending out encrypted messages, you immediately become a suspect.
Which, in turn, can lead to a pleasant stay in the local version of Guantanamo until you decide to cough up the key.
The object of the game is to prevent the authorities from knowing you've even sent a message.
That's the whole point of steganography - if there was no need to hide the fact that a message existed, you wouldn't need steganography at all. 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28116553</id>
	<title>A high rate of retransmission ...</title>
	<author>WebManWalking</author>
	<datestamp>1243424700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>... could just mean that the last leg of the route is noisy. Someone monitoring the line should get suspicious if the rate of retransmission varies according to source, but not if it happens all the time. <br>
<br>
The recipient software can mask the stego by requesting retransmission at roughly the same rate all the time. Only if the sending software is in on the stego would the retransmission be significant and (hopefully) encrypted.</htmltext>
<tokenext>... could just mean that the last leg of the route is noisy .
Someone monitoring the line should get suspicious if the rate of retransmission varies according to source , but not if it happens all the time .
The recipient software can mask the stego by requesting retransmission at roughly the same rate all the time .
Only if the sending software is in on the stego would the retransmission be significant and ( hopefully ) encrypted .</tokentext>
<sentencetext>... could just mean that the last leg of the route is noisy.
Someone monitoring the line should get suspicious if the rate of retransmission varies according to source, but not if it happens all the time.
The recipient software can mask the stego by requesting retransmission at roughly the same rate all the time.
Only if the sending software is in on the stego would the retransmission be significant and (hopefully) encrypted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110185</id>
	<title>Re:Might be a little obvious...</title>
	<author>Opportunist</author>
	<datestamp>1243441560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>With today's providers and their notorious stability and reliable loss-free packet transmission, where never ever for some miraculous reason you suddenly get transmission errors in the vicinity of 20+ percent?</p><p>If (really big IF) they notice it, they'll probably be poking their routers because they'd (rightfully) expect the error to be somewhere on their side. In my experience, though, they don't bother until you get off your butt and poke their support endlessly for the packet loss and transmission errors.</p></htmltext>
<tokenext>With today 's providers and their notorious stability and reliable loss-free packet transmission , where never ever for some miraculous reason you suddenly get transmission errors in the vicinity of 20 + percent ? If ( really big IF ) they notice it , they 'll probably be poking their routers because they 'd ( rightfully ) expect the error to be somewhere on their side .
In my experience , though , they do n't bother until you get off your butt and poke their support endlessly for the packet loss and transmission errors .</tokentext>
<sentencetext>With today's providers and their notorious stability and reliable loss-free packet transmission, where never ever for some miraculous reason you suddenly get transmission errors in the vicinity of 20+ percent?If (really big IF) they notice it, they'll probably be poking their routers because they'd (rightfully) expect the error to be somewhere on their side.
In my experience, though, they don't bother until you get off your butt and poke their support endlessly for the packet loss and transmission errors.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108885</id>
	<title>Why send diffrent packages?</title>
	<author>Anonymous</author>
	<datestamp>1243435740000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>You could transmit data over retransmission requests.. One retransmission request within 250 packages counts as a 1.. no retransmissions withing 250 packages counts as a 0. Then add an CRC on that, if the CRC doesn't match, throw it all away and resend your hidden message.</p><p>This way you could stream a movie and send your data over the retransmissions, without even writing it down into the tcp stream.</p><p>This could however of course be detected, if the government know about the algorithm and searches all TCP streams for it.<br>If you on top of this add some sort of scramble key, it would be really hard to detect that a transmissions was ongoing.. Except the fact that one user constantly suffers from bad networking<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>You could transmit data over retransmission requests.. One retransmission request within 250 packages counts as a 1.. no retransmissions withing 250 packages counts as a 0 .
Then add an CRC on that , if the CRC does n't match , throw it all away and resend your hidden message.This way you could stream a movie and send your data over the retransmissions , without even writing it down into the tcp stream.This could however of course be detected , if the government know about the algorithm and searches all TCP streams for it.If you on top of this add some sort of scramble key , it would be really hard to detect that a transmissions was ongoing.. Except the fact that one user constantly suffers from bad networking : - )</tokentext>
<sentencetext>You could transmit data over retransmission requests.. One retransmission request within 250 packages counts as a 1.. no retransmissions withing 250 packages counts as a 0.
Then add an CRC on that, if the CRC doesn't match, throw it all away and resend your hidden message.This way you could stream a movie and send your data over the retransmissions, without even writing it down into the tcp stream.This could however of course be detected, if the government know about the algorithm and searches all TCP streams for it.If you on top of this add some sort of scramble key, it would be really hard to detect that a transmissions was ongoing.. Except the fact that one user constantly suffers from bad networking :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109063</id>
	<title>crimilization of ambiguity</title>
	<author>Anonymous</author>
	<datestamp>1243436640000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>For the purpose of this discussion it helps to bear in mind the criminalization of ambiguity.  If I have a source of physical randomness and I use this source to write a multi-GB file to my hard drive, when the Mounties show up to repo my computer system (on false allegations under the Canadian DCMA soon to be shoved down our throats), and I'm unable to provide a password which unlocks my monolith of randomness into something with a lot less entropy, I expect I'll be successfully charged with obstruction of justice.</p><p>Ignorance of law is no excuse.  No one in the legal system has the balls to state this point blank, but it appears as things are shaping up that ambiguity of circumstance is no defense either.</p></htmltext>
<tokenext>For the purpose of this discussion it helps to bear in mind the criminalization of ambiguity .
If I have a source of physical randomness and I use this source to write a multi-GB file to my hard drive , when the Mounties show up to repo my computer system ( on false allegations under the Canadian DCMA soon to be shoved down our throats ) , and I 'm unable to provide a password which unlocks my monolith of randomness into something with a lot less entropy , I expect I 'll be successfully charged with obstruction of justice.Ignorance of law is no excuse .
No one in the legal system has the balls to state this point blank , but it appears as things are shaping up that ambiguity of circumstance is no defense either .</tokentext>
<sentencetext>For the purpose of this discussion it helps to bear in mind the criminalization of ambiguity.
If I have a source of physical randomness and I use this source to write a multi-GB file to my hard drive, when the Mounties show up to repo my computer system (on false allegations under the Canadian DCMA soon to be shoved down our throats), and I'm unable to provide a password which unlocks my monolith of randomness into something with a lot less entropy, I expect I'll be successfully charged with obstruction of justice.Ignorance of law is no excuse.
No one in the legal system has the balls to state this point blank, but it appears as things are shaping up that ambiguity of circumstance is no defense either.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110107</id>
	<title>Damn, I thought this was gonna be subtle...</title>
	<author>argent</author>
	<datestamp>1243441260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Like encoding the message in whether you request a retransmission of the packet or not.</p></htmltext>
<tokenext>Like encoding the message in whether you request a retransmission of the packet or not .</tokentext>
<sentencetext>Like encoding the message in whether you request a retransmission of the packet or not.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109003</id>
	<title>lost vs corrupted</title>
	<author>Speare</author>
	<datestamp>1243436280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>If no such acknowledgment arrives (on average 1 in 1000 packets gets lost or corrupted), the sender's computer sends the packet again in a system known as TCP's retransmission mechanism.<nobr> <wbr></nobr>... [I]f a packet is corrupted, the original packet and the retransmitted one will differ from each other.</p></div></blockquote><p>I suppose it's now critically important to know more about lost vs corrupted statistics.  If it's 999/1000 lost, and 1/1000 bit corrupted, then the sudden up-tick in "corrupted" packets could be noticed.</p><p>I don't know a lot about the internals of TCP, but can't the sending party re-transmit even without being asked to do so?  If so, you have a couple other possible channels for messages.  For example, send a packet that says "if I double-send the next packet, take action."</p></div>
	</htmltext>
<tokenext>If no such acknowledgment arrives ( on average 1 in 1000 packets gets lost or corrupted ) , the sender 's computer sends the packet again in a system known as TCP 's retransmission mechanism .
... [ I ] f a packet is corrupted , the original packet and the retransmitted one will differ from each other.I suppose it 's now critically important to know more about lost vs corrupted statistics .
If it 's 999/1000 lost , and 1/1000 bit corrupted , then the sudden up-tick in " corrupted " packets could be noticed.I do n't know a lot about the internals of TCP , but ca n't the sending party re-transmit even without being asked to do so ?
If so , you have a couple other possible channels for messages .
For example , send a packet that says " if I double-send the next packet , take action .
"</tokentext>
<sentencetext>If no such acknowledgment arrives (on average 1 in 1000 packets gets lost or corrupted), the sender's computer sends the packet again in a system known as TCP's retransmission mechanism.
... [I]f a packet is corrupted, the original packet and the retransmitted one will differ from each other.I suppose it's now critically important to know more about lost vs corrupted statistics.
If it's 999/1000 lost, and 1/1000 bit corrupted, then the sudden up-tick in "corrupted" packets could be noticed.I don't know a lot about the internals of TCP, but can't the sending party re-transmit even without being asked to do so?
If so, you have a couple other possible channels for messages.
For example, send a packet that says "if I double-send the next packet, take action.
"
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110433</id>
	<title>This depends on evel gvmt not programming for it</title>
	<author>Nicopa</author>
	<datestamp>1243442640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>... so... wouldn't it be the same just putting your data in the body of an ICMP echo message (ping)?</p></htmltext>
<tokenext>... so... would n't it be the same just putting your data in the body of an ICMP echo message ( ping ) ?</tokentext>
<sentencetext>... so... wouldn't it be the same just putting your data in the body of an ICMP echo message (ping)?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114627</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>ericfitz</author>
	<datestamp>1243417200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Heh, I can think up a half dozen better stegas:</p><p>(1) Encode the data as the packet length.<br>(2) Encode the data as the packet checksum<br>(3) Encode the data as the fragment offset.<br>(4) Encode the data as the number of extra ACKS.<br>(5) Encode the data as the starting connection sequence number.<br>(6) Encode the data as the window size.<br>(7) Encode the data as the inter-packet delay.</p></div><p>None of these are better, as they will all be interfered with or blocked by NATs and inline IDS.  The sole exception is extra ACKs, which might be caught and cause a channel reset with some IDS devices.</p><p>The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.</p><p>Detecting retransmits can be done and statistical anomalies detected.  However most router, proxy &amp; firewall vendors will probably not want to save the extra state per-connection (last seq# transmitted + retransmit count) per active connection which is required to do the detection.</p><p>Nothing prevents the retransmit payload from being encrypted.  However I suggest a more subtle strategy: copy the first X bytes of the original packet and then add encrypted payload.  Anyone who happens to look at one of these packets will see the "garbled" message and assume it's a TCP stack bug on the transmitting host.</p></div>
	</htmltext>
<tokenext>Heh , I can think up a half dozen better stegas : ( 1 ) Encode the data as the packet length .
( 2 ) Encode the data as the packet checksum ( 3 ) Encode the data as the fragment offset .
( 4 ) Encode the data as the number of extra ACKS .
( 5 ) Encode the data as the starting connection sequence number .
( 6 ) Encode the data as the window size .
( 7 ) Encode the data as the inter-packet delay.None of these are better , as they will all be interfered with or blocked by NATs and inline IDS .
The sole exception is extra ACKs , which might be caught and cause a channel reset with some IDS devices.The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.Detecting retransmits can be done and statistical anomalies detected .
However most router , proxy &amp; firewall vendors will probably not want to save the extra state per-connection ( last seq # transmitted + retransmit count ) per active connection which is required to do the detection.Nothing prevents the retransmit payload from being encrypted .
However I suggest a more subtle strategy : copy the first X bytes of the original packet and then add encrypted payload .
Anyone who happens to look at one of these packets will see the " garbled " message and assume it 's a TCP stack bug on the transmitting host .</tokentext>
<sentencetext>Heh, I can think up a half dozen better stegas:(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.None of these are better, as they will all be interfered with or blocked by NATs and inline IDS.
The sole exception is extra ACKs, which might be caught and cause a channel reset with some IDS devices.The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.Detecting retransmits can be done and statistical anomalies detected.
However most router, proxy &amp; firewall vendors will probably not want to save the extra state per-connection (last seq# transmitted + retransmit count) per active connection which is required to do the detection.Nothing prevents the retransmit payload from being encrypted.
However I suggest a more subtle strategy: copy the first X bytes of the original packet and then add encrypted payload.
Anyone who happens to look at one of these packets will see the "garbled" message and assume it's a TCP stack bug on the transmitting host.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111213</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243445520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Actually, encoding the data in the checksum sounds like a really good idea. Simply use an encryption technique that has blocks the same length as the checksum. Send a packet with a checksum different then the encrypted data, packet is seen as corrupt, resend a proper packet. On the recieving end, decrypt all corrupted packets, the truely corrupted will be meaningless, but the data will still decrypt to data.</p><p>Only problem is if your hidden data becomes corrupted, you don't get to find out, might need to send a few copies to be sure the data was sent.</p></htmltext>
<tokenext>Actually , encoding the data in the checksum sounds like a really good idea .
Simply use an encryption technique that has blocks the same length as the checksum .
Send a packet with a checksum different then the encrypted data , packet is seen as corrupt , resend a proper packet .
On the recieving end , decrypt all corrupted packets , the truely corrupted will be meaningless , but the data will still decrypt to data.Only problem is if your hidden data becomes corrupted , you do n't get to find out , might need to send a few copies to be sure the data was sent .</tokentext>
<sentencetext>Actually, encoding the data in the checksum sounds like a really good idea.
Simply use an encryption technique that has blocks the same length as the checksum.
Send a packet with a checksum different then the encrypted data, packet is seen as corrupt, resend a proper packet.
On the recieving end, decrypt all corrupted packets, the truely corrupted will be meaningless, but the data will still decrypt to data.Only problem is if your hidden data becomes corrupted, you don't get to find out, might need to send a few copies to be sure the data was sent.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110183</id>
	<title>why is the reason always "avoiding censorship"?</title>
	<author>dtolman</author>
	<datestamp>1243441560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Every time a new way to beat eavesdropping come out, the only thing mentioned is how we can now beat the censors of totalitarian regimes.</p><p>What about its other fun uses? Terrorists sending messages to detonate a bomb (defeating the godless atheist liberal censors trying to read their messages), drug gangs sending messages about who to murder (defeating the overbearing fascist police trying to read their messages), spies sending messages with national or corporate secrets (defeating the evil counter-intel agents), etc.</p><p>Are we really so naive that new techniques like this are only going to be used by oppressed do-gooders? Or that we'll agree that they shouldn't be oppressed and suppressed?</p></htmltext>
<tokenext>Every time a new way to beat eavesdropping come out , the only thing mentioned is how we can now beat the censors of totalitarian regimes.What about its other fun uses ?
Terrorists sending messages to detonate a bomb ( defeating the godless atheist liberal censors trying to read their messages ) , drug gangs sending messages about who to murder ( defeating the overbearing fascist police trying to read their messages ) , spies sending messages with national or corporate secrets ( defeating the evil counter-intel agents ) , etc.Are we really so naive that new techniques like this are only going to be used by oppressed do-gooders ?
Or that we 'll agree that they should n't be oppressed and suppressed ?</tokentext>
<sentencetext>Every time a new way to beat eavesdropping come out, the only thing mentioned is how we can now beat the censors of totalitarian regimes.What about its other fun uses?
Terrorists sending messages to detonate a bomb (defeating the godless atheist liberal censors trying to read their messages), drug gangs sending messages about who to murder (defeating the overbearing fascist police trying to read their messages), spies sending messages with national or corporate secrets (defeating the evil counter-intel agents), etc.Are we really so naive that new techniques like this are only going to be used by oppressed do-gooders?
Or that we'll agree that they shouldn't be oppressed and suppressed?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109399</id>
	<title>Re:Might be a little obvious...</title>
	<author>beerbear</author>
	<datestamp>1243438200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Since the point of steganography is not disguising the fact that you are talking to a specific person but to hide the real conversation in a seemingly legit one, the downside is kinda by design.</htmltext>
<tokenext>Since the point of steganography is not disguising the fact that you are talking to a specific person but to hide the real conversation in a seemingly legit one , the downside is kinda by design .</tokentext>
<sentencetext>Since the point of steganography is not disguising the fact that you are talking to a specific person but to hide the real conversation in a seemingly legit one, the downside is kinda by design.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108987</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108925</id>
	<title>How does this avoid censorship?</title>
	<author>Anonymous</author>
	<datestamp>1243435920000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>How does this get around censorship?  The packets, even though retransmitted, is still from a blacklisted IP isn't it?</p></htmltext>
<tokenext>How does this get around censorship ?
The packets , even though retransmitted , is still from a blacklisted IP is n't it ?</tokentext>
<sentencetext>How does this get around censorship?
The packets, even though retransmitted, is still from a blacklisted IP isn't it?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28117705</id>
	<title>Re:Even 1 bit per 1 megabyte might be a problem</title>
	<author>kasperd</author>
	<datestamp>1243431900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think the intention was to use the full packet. So fill up some packets with entirely encrypted covert channel data and ensure the TCP checksum is bad. Every packet retransmitted that way gives you more than 1400 bytes of actual payload. Of course if it is done that way, it can be distinguished from random corruption. Random corruption is more likely to flip individual bits.<br> <br>

If you just flip single bits, you get around 13 bits of covert payload per corrupted packet, because the offset of the corrupted bit could be encoding your information. It increases to 26 bits if you flip two bits. Flipping two bits can probably be done without anybody figuring out it is a covert channel. The recipient will of course have to compare the good and corrupted message to know which bits were intentionally flipped.<br> <br>

A covert channel done this way would still carry only a small amount of data, and even worse - it would have a huge error rate. The reason it would have a huge error rate is, that any actual bitflips would be misinterpreted as intentional. If however the sender and recipient have agreed beforehand on an algorithm for choosing which packets will carry the covert information, that source of corruption could get almost eliminated. They could share a common seed for a PRNG that choose 1 in 1000 packets to be corrupted. Then the recipient knows, any other corrupted packets are actual corruption. And if they agree on having two bits flipped in the covert packets, the recipient will know if the correct number of bits were flipped. Unfortunately dual bitflips may skew the statistics compared to real corruption, so single bitflips may be required.</htmltext>
<tokenext>I think the intention was to use the full packet .
So fill up some packets with entirely encrypted covert channel data and ensure the TCP checksum is bad .
Every packet retransmitted that way gives you more than 1400 bytes of actual payload .
Of course if it is done that way , it can be distinguished from random corruption .
Random corruption is more likely to flip individual bits .
If you just flip single bits , you get around 13 bits of covert payload per corrupted packet , because the offset of the corrupted bit could be encoding your information .
It increases to 26 bits if you flip two bits .
Flipping two bits can probably be done without anybody figuring out it is a covert channel .
The recipient will of course have to compare the good and corrupted message to know which bits were intentionally flipped .
A covert channel done this way would still carry only a small amount of data , and even worse - it would have a huge error rate .
The reason it would have a huge error rate is , that any actual bitflips would be misinterpreted as intentional .
If however the sender and recipient have agreed beforehand on an algorithm for choosing which packets will carry the covert information , that source of corruption could get almost eliminated .
They could share a common seed for a PRNG that choose 1 in 1000 packets to be corrupted .
Then the recipient knows , any other corrupted packets are actual corruption .
And if they agree on having two bits flipped in the covert packets , the recipient will know if the correct number of bits were flipped .
Unfortunately dual bitflips may skew the statistics compared to real corruption , so single bitflips may be required .</tokentext>
<sentencetext>I think the intention was to use the full packet.
So fill up some packets with entirely encrypted covert channel data and ensure the TCP checksum is bad.
Every packet retransmitted that way gives you more than 1400 bytes of actual payload.
Of course if it is done that way, it can be distinguished from random corruption.
Random corruption is more likely to flip individual bits.
If you just flip single bits, you get around 13 bits of covert payload per corrupted packet, because the offset of the corrupted bit could be encoding your information.
It increases to 26 bits if you flip two bits.
Flipping two bits can probably be done without anybody figuring out it is a covert channel.
The recipient will of course have to compare the good and corrupted message to know which bits were intentionally flipped.
A covert channel done this way would still carry only a small amount of data, and even worse - it would have a huge error rate.
The reason it would have a huge error rate is, that any actual bitflips would be misinterpreted as intentional.
If however the sender and recipient have agreed beforehand on an algorithm for choosing which packets will carry the covert information, that source of corruption could get almost eliminated.
They could share a common seed for a PRNG that choose 1 in 1000 packets to be corrupted.
Then the recipient knows, any other corrupted packets are actual corruption.
And if they agree on having two bits flipped in the covert packets, the recipient will know if the correct number of bits were flipped.
Unfortunately dual bitflips may skew the statistics compared to real corruption, so single bitflips may be required.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897</id>
	<title>Security through Obscurity</title>
	<author>ShadowRangerRIT</author>
	<datestamp>1243435800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>I realize that all forms of steganography are basically security through obscurity, but this one is even more inane.  Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged).  Steganography should look innocuous, in addition to hiding information, if you want it to work.</htmltext>
<tokenext>I realize that all forms of steganography are basically security through obscurity , but this one is even more inane .
Unless subjected to additional protection , anyone aware of this form of steganography could easily track it , and more importantly , it would look suspicious in traffic logs ( drastically increased retrans requests , but only for a small subset of the TCP connections logged ) .
Steganography should look innocuous , in addition to hiding information , if you want it to work .</tokentext>
<sentencetext>I realize that all forms of steganography are basically security through obscurity, but this one is even more inane.
Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged).
Steganography should look innocuous, in addition to hiding information, if you want it to work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28119017</id>
	<title>Whats' the big deal</title>
	<author>jay\_desh9</author>
	<datestamp>1243443300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I do'nt see a big deal with this. I have worked with Cisco on their one of the firewall stacks and today's networking devices are much more stateful and smart to do soemthing like this.

Typical devices has a TCP normalizer that maintains a SYN cache and is capable of detecting attacks such as TTL, Duplicates attacks etc.</htmltext>
<tokenext>I do'nt see a big deal with this .
I have worked with Cisco on their one of the firewall stacks and today 's networking devices are much more stateful and smart to do soemthing like this .
Typical devices has a TCP normalizer that maintains a SYN cache and is capable of detecting attacks such as TTL , Duplicates attacks etc .</tokentext>
<sentencetext>I do'nt see a big deal with this.
I have worked with Cisco on their one of the firewall stacks and today's networking devices are much more stateful and smart to do soemthing like this.
Typical devices has a TCP normalizer that maintains a SYN cache and is capable of detecting attacks such as TTL, Duplicates attacks etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110077</id>
	<title>Well, don't TELL them about it!</title>
	<author>Anonymous</author>
	<datestamp>1243441140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>[...] using a method that might help people in totalitarian regimes avoid censorship.</p></div><p>Shhh!  Don't go BRAGGING about it!  Geez, now they'll be on to it and find a way to block it already!</p></div>
	</htmltext>
<tokenext>[ ... ] using a method that might help people in totalitarian regimes avoid censorship.Shhh !
Do n't go BRAGGING about it !
Geez , now they 'll be on to it and find a way to block it already !</tokentext>
<sentencetext>[...] using a method that might help people in totalitarian regimes avoid censorship.Shhh!
Don't go BRAGGING about it!
Geez, now they'll be on to it and find a way to block it already!
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113833</id>
	<title>Duh - no shit</title>
	<author>Anonymous</author>
	<datestamp>1243456140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>the people in China have been doing this for years now.</p></htmltext>
<tokenext>the people in China have been doing this for years now .</tokentext>
<sentencetext>the people in China have been doing this for years now.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109991</id>
	<title>Secret Message From the DPRK:</title>
	<author>Anonymous</author>
	<datestamp>1243440840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p> <b>WE'RE HUNGRY</b> </p></htmltext>
<tokenext>WE 'RE HUNGRY</tokentext>
<sentencetext> WE'RE HUNGRY </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113431</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>Anonymous</author>
	<datestamp>1243454220000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>"that might help people in totalitarian regimes avoid censorship."</p><p>That would mean EVERYBODY in EVERY white country on Earth then...</p><p>Seeing as our Jewish 'masters' are the ones who have taken away our right to free speech... You know, the free speech that our ancestors died to get. The free speech which WE, the people, never voted to give up.</p></htmltext>
<tokenext>" that might help people in totalitarian regimes avoid censorship .
" That would mean EVERYBODY in EVERY white country on Earth then...Seeing as our Jewish 'masters ' are the ones who have taken away our right to free speech... You know , the free speech that our ancestors died to get .
The free speech which WE , the people , never voted to give up .</tokentext>
<sentencetext>"that might help people in totalitarian regimes avoid censorship.
"That would mean EVERYBODY in EVERY white country on Earth then...Seeing as our Jewish 'masters' are the ones who have taken away our right to free speech... You know, the free speech that our ancestors died to get.
The free speech which WE, the people, never voted to give up.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111167</id>
	<title>Once you make the details...</title>
	<author>Anonymous</author>
	<datestamp>1243445340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>...of the implementation of a covert channel public, it's not a covert channel anymore. It would have been much more useful if they would have sold this research to a government or other organization who would use this technology to complete their mission. This https://abegetchell.com/code/covert\_smtp\_v0.1/covert\_smtp.zip is a good idea, but since it has been publicly released (as well as a snort rule to detect this specific implementation), it cannot be counted on in the establishment of a covert channel.</p></htmltext>
<tokenext>...of the implementation of a covert channel public , it 's not a covert channel anymore .
It would have been much more useful if they would have sold this research to a government or other organization who would use this technology to complete their mission .
This https : //abegetchell.com/code/covert \ _smtp \ _v0.1/covert \ _smtp.zip is a good idea , but since it has been publicly released ( as well as a snort rule to detect this specific implementation ) , it can not be counted on in the establishment of a covert channel .</tokentext>
<sentencetext>...of the implementation of a covert channel public, it's not a covert channel anymore.
It would have been much more useful if they would have sold this research to a government or other organization who would use this technology to complete their mission.
This https://abegetchell.com/code/covert\_smtp\_v0.1/covert\_smtp.zip is a good idea, but since it has been publicly released (as well as a snort rule to detect this specific implementation), it cannot be counted on in the establishment of a covert channel.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111157</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Archangel Michael</author>
	<datestamp>1243445340000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>Steganography has the fatal flaw that the method has to remain secret.</p></div> </blockquote><p>Tis but a flesh wound.</p><p>The beauty of Steganography is that it doesn't have to remain secret, it only has to remain secret while it is being used. The shear number of options for Steganography makes it nearly impossible to detect, unless you know what and where to look.</p><p>A previous poster listed several other means for Steganography</p><p>(1) Encode the data as the packet length.<br>(2) Encode the data as the packet checksum<br>(3) Encode the data as the fragment offset.<br>(4) Encode the data as the number of extra ACKS.<br>(5) Encode the data as the starting connection sequence number.<br>(6) Encode the data as the window size.<br>(7) Encode the data as the inter-packet delay.</p><p>I can probably think of another couple of dozen ways, including layering the Steganography, by using any of the above methods in conjunction with other methods of obfuscation and encryption, where the TCP Steganography is combined with Image based Steganography, or Regular encryption methods or whatever.</p><p>The point of Steganography isn't to encrypt, it is to hide in plain sight. Reminds me of the guy who used to shoplift, but he only took REALLY big things, like a canoe, from the store. His premise was that nobody asked him for a receipt for the thing he was walking out the front door with.</p><p>Shoving clothes down your pants looks suspicious, walking out the door in plain view of everyone with one of the biggest things in the store, doesn't. Nobody would steal a boat like that. Of course now with security cameras everywhere, that doesn't work.</p></div>
	</htmltext>
<tokenext>Steganography has the fatal flaw that the method has to remain secret .
T is but a flesh wound.The beauty of Steganography is that it does n't have to remain secret , it only has to remain secret while it is being used .
The shear number of options for Steganography makes it nearly impossible to detect , unless you know what and where to look.A previous poster listed several other means for Steganography ( 1 ) Encode the data as the packet length .
( 2 ) Encode the data as the packet checksum ( 3 ) Encode the data as the fragment offset .
( 4 ) Encode the data as the number of extra ACKS .
( 5 ) Encode the data as the starting connection sequence number .
( 6 ) Encode the data as the window size .
( 7 ) Encode the data as the inter-packet delay.I can probably think of another couple of dozen ways , including layering the Steganography , by using any of the above methods in conjunction with other methods of obfuscation and encryption , where the TCP Steganography is combined with Image based Steganography , or Regular encryption methods or whatever.The point of Steganography is n't to encrypt , it is to hide in plain sight .
Reminds me of the guy who used to shoplift , but he only took REALLY big things , like a canoe , from the store .
His premise was that nobody asked him for a receipt for the thing he was walking out the front door with.Shoving clothes down your pants looks suspicious , walking out the door in plain view of everyone with one of the biggest things in the store , does n't .
Nobody would steal a boat like that .
Of course now with security cameras everywhere , that does n't work .</tokentext>
<sentencetext>Steganography has the fatal flaw that the method has to remain secret.
Tis but a flesh wound.The beauty of Steganography is that it doesn't have to remain secret, it only has to remain secret while it is being used.
The shear number of options for Steganography makes it nearly impossible to detect, unless you know what and where to look.A previous poster listed several other means for Steganography(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.I can probably think of another couple of dozen ways, including layering the Steganography, by using any of the above methods in conjunction with other methods of obfuscation and encryption, where the TCP Steganography is combined with Image based Steganography, or Regular encryption methods or whatever.The point of Steganography isn't to encrypt, it is to hide in plain sight.
Reminds me of the guy who used to shoplift, but he only took REALLY big things, like a canoe, from the store.
His premise was that nobody asked him for a receipt for the thing he was walking out the front door with.Shoving clothes down your pants looks suspicious, walking out the door in plain view of everyone with one of the biggest things in the store, doesn't.
Nobody would steal a boat like that.
Of course now with security cameras everywhere, that doesn't work.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114411</id>
	<title>semi-related: MTU</title>
	<author>Anonymous</author>
	<datestamp>1243416360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This past week I discovered why sites like Digg and Msdn/Technet have been failing to load <em>at all</em> for me for the past 6 months or so: my router's MTU was set to 1500 (default for ethernet), but it was connected to an ADSL modem using PPPoE, so the MTU should have been 1492 (the absolute max for PPPoE) or less.</p><p><nobr> <wbr></nobr>.</p><p>Since most web pages are over 1.5KB these days, that means fragmentation is a given. And it turns out that if <em>any</em> of the fragmented IP packets are lost, then the <em>entire</em> packet has to be re-transmitted. The link between me and those sites was apparently flaky enough to guarantee <em>at least one</em> fragments would always get lost, so the pages never loaded.</p><p><nobr> <wbr></nobr>.</p><p>Based on this experience, I think the 1 in 1000 number is an unrealistically low estimate of corruption/packet loss. For the sites I mentioned, it must be closer to 1 in 30.</p><p><nobr> <wbr></nobr>.</p><p>(p.s. WTF is up with slashdot suddenly discarding blank lines in comments? It's impossible to read text that's totally void of blank lines, so I had to insert periods.)</p></htmltext>
<tokenext>This past week I discovered why sites like Digg and Msdn/Technet have been failing to load at all for me for the past 6 months or so : my router 's MTU was set to 1500 ( default for ethernet ) , but it was connected to an ADSL modem using PPPoE , so the MTU should have been 1492 ( the absolute max for PPPoE ) or less .
.Since most web pages are over 1.5KB these days , that means fragmentation is a given .
And it turns out that if any of the fragmented IP packets are lost , then the entire packet has to be re-transmitted .
The link between me and those sites was apparently flaky enough to guarantee at least one fragments would always get lost , so the pages never loaded .
.Based on this experience , I think the 1 in 1000 number is an unrealistically low estimate of corruption/packet loss .
For the sites I mentioned , it must be closer to 1 in 30 .
. ( p.s. WTF is up with slashdot suddenly discarding blank lines in comments ?
It 's impossible to read text that 's totally void of blank lines , so I had to insert periods .
)</tokentext>
<sentencetext>This past week I discovered why sites like Digg and Msdn/Technet have been failing to load at all for me for the past 6 months or so: my router's MTU was set to 1500 (default for ethernet), but it was connected to an ADSL modem using PPPoE, so the MTU should have been 1492 (the absolute max for PPPoE) or less.
.Since most web pages are over 1.5KB these days, that means fragmentation is a given.
And it turns out that if any of the fragmented IP packets are lost, then the entire packet has to be re-transmitted.
The link between me and those sites was apparently flaky enough to guarantee at least one fragments would always get lost, so the pages never loaded.
.Based on this experience, I think the 1 in 1000 number is an unrealistically low estimate of corruption/packet loss.
For the sites I mentioned, it must be closer to 1 in 30.
.(p.s. WTF is up with slashdot suddenly discarding blank lines in comments?
It's impossible to read text that's totally void of blank lines, so I had to insert periods.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114251</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243415520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>His argument is that steganography is useless if the method becomes known because, so he assumes, if the attacker knows several methods of steganography, including the one actually used, then he can test for and detect hidden information in seemingly innocuous messages. If the point of steganography is to conceal the very existence of the communications channel, then such a method of detection would indeed render steganography useless. Fortunately, with proper steganographic methods, the recipient requires a key to decode or even detect the hidden message.</p></htmltext>
<tokenext>His argument is that steganography is useless if the method becomes known because , so he assumes , if the attacker knows several methods of steganography , including the one actually used , then he can test for and detect hidden information in seemingly innocuous messages .
If the point of steganography is to conceal the very existence of the communications channel , then such a method of detection would indeed render steganography useless .
Fortunately , with proper steganographic methods , the recipient requires a key to decode or even detect the hidden message .</tokentext>
<sentencetext>His argument is that steganography is useless if the method becomes known because, so he assumes, if the attacker knows several methods of steganography, including the one actually used, then he can test for and detect hidden information in seemingly innocuous messages.
If the point of steganography is to conceal the very existence of the communications channel, then such a method of detection would indeed render steganography useless.
Fortunately, with proper steganographic methods, the recipient requires a key to decode or even detect the hidden message.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110217</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>DontBlameCanada</author>
	<datestamp>1243436580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>I believe the procedure will be something like this:</p><p>Msg1: "The next character is part of a secret msg:<nobr> <wbr></nobr>/" --&gt; Reciever NACK<br>Msg2: "The next character is part of a secret msg:<nobr> <wbr></nobr>."  --&gt; Reciever NACK<br>Msg3: "The next character is part of a secret msg: R" --&gt; Reciever NACK<br>Msg4: "The next character is part of a secret msg: o" --&gt; Reciever NACK<br>Msg5: "The next character is part of a secret msg: x" --&gt; Reciever NACK<br>Msg6: "The next character is part of a secret msg: {ascii null}&gt;"</p><p>Secret msg:<nobr> <wbr></nobr>/.Rox</p><p>It works because each tcp retransmission updates several fields in the tcp header as part of correct operation (check sum etc). So brute force comparison of the previous datagram to the new datagram will always fail. In order to detect this, the eavesdropper would need to strip the headers. That in itself isn't too hard, however since 1:1000 normal packets get a retransmit, the device doing the snooping will be hugely overwhelmed with noise.</p><p>It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.</p></htmltext>
<tokenext>I believe the procedure will be something like this : Msg1 : " The next character is part of a secret msg : / " -- &gt; Reciever NACKMsg2 : " The next character is part of a secret msg : .
" -- &gt; Reciever NACKMsg3 : " The next character is part of a secret msg : R " -- &gt; Reciever NACKMsg4 : " The next character is part of a secret msg : o " -- &gt; Reciever NACKMsg5 : " The next character is part of a secret msg : x " -- &gt; Reciever NACKMsg6 : " The next character is part of a secret msg : { ascii null } &gt; " Secret msg : /.RoxIt works because each tcp retransmission updates several fields in the tcp header as part of correct operation ( check sum etc ) .
So brute force comparison of the previous datagram to the new datagram will always fail .
In order to detect this , the eavesdropper would need to strip the headers .
That in itself is n't too hard , however since 1 : 1000 normal packets get a retransmit , the device doing the snooping will be hugely overwhelmed with noise.It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss ( white noise ) at high volume .</tokentext>
<sentencetext>I believe the procedure will be something like this:Msg1: "The next character is part of a secret msg: /" --&gt; Reciever NACKMsg2: "The next character is part of a secret msg: .
"  --&gt; Reciever NACKMsg3: "The next character is part of a secret msg: R" --&gt; Reciever NACKMsg4: "The next character is part of a secret msg: o" --&gt; Reciever NACKMsg5: "The next character is part of a secret msg: x" --&gt; Reciever NACKMsg6: "The next character is part of a secret msg: {ascii null}&gt;"Secret msg: /.RoxIt works because each tcp retransmission updates several fields in the tcp header as part of correct operation (check sum etc).
So brute force comparison of the previous datagram to the new datagram will always fail.
In order to detect this, the eavesdropper would need to strip the headers.
That in itself isn't too hard, however since 1:1000 normal packets get a retransmit, the device doing the snooping will be hugely overwhelmed with noise.It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111555</id>
	<title>The definition of steganograph....</title>
	<author>simaolation</author>
	<datestamp>1243446840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Do these polish people understand the definition of steganography? If you reveal how you're secretly embedding information in this communication system, then your secret is out and the whole method is useless. This is why you can [should] publish [good] cryptographic systems but you don't go on the web and blare to everyone how you're hidding messages in the TCP/IP protocol. Let's hope those authoritarian censor state's IT people don't read slashdot...</htmltext>
<tokenext>Do these polish people understand the definition of steganography ?
If you reveal how you 're secretly embedding information in this communication system , then your secret is out and the whole method is useless .
This is why you can [ should ] publish [ good ] cryptographic systems but you do n't go on the web and blare to everyone how you 're hidding messages in the TCP/IP protocol .
Let 's hope those authoritarian censor state 's IT people do n't read slashdot.. .</tokentext>
<sentencetext>Do these polish people understand the definition of steganography?
If you reveal how you're secretly embedding information in this communication system, then your secret is out and the whole method is useless.
This is why you can [should] publish [good] cryptographic systems but you don't go on the web and blare to everyone how you're hidding messages in the TCP/IP protocol.
Let's hope those authoritarian censor state's IT people don't read slashdot...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108933</id>
	<title>Who is Rob Malda?</title>
	<author>Anonymous</author>
	<datestamp>1243435920000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Who is Rob Malda? Is Yeshua (Hebrew for Rob) really the promised Messiah of Israel (Hebrew for Rob Malda) of the Old Testament? Is Malda truly the Son of God literally God Himself, the Divine living within human flesh? Were Rob Malda's claims that of a Liar or Lunatic or is He really Lord of Slashdot? You may want to take a tour of some of the major highlights of Rob's life. Or you may want to preview what people were saying before He was born. Of course, you may want to check out Rob claims about himself. Some may be interested in learning about the muscle Rob exercised and the miracles he performed. Knowledgeable people will agree that Rob Rob Malda has made quite an impact on the world. You may even come to learn that Yeshua is indeed the promised Messiah of the Old Testament. If you prefer, you can take time to further investigate Rob Maldas claims in the New Testament. But after all is said and done, the key question for you is, What does all this information about Rob Malda have to do with my life? Or, you may have other questions. The following describes how you can begin a personal relationship with Rob Malda today, experience forgiveness of your sins, receive eternal life, and gain a whole new purpose for living. ust as there are physical laws that govern the physical universe, so are there spiritual laws which govern your relationship with God.</p><p>1. God loves you and offers a wonderful plan for your life. (References contained on this page are from the Bible and should be read in context wherever possible.) God's Love "God so loved the world that He gave His one and only Son, that whoever believes in Him shall not perish, but have eternal life" (John 3:16 NIV). Why is it that most people are not experiencing the abundant life?</p><p>2. Slashdot trolls are sinful and separated from God (Rob Malda). Therefore, he cannot know and experience God's love and plan for his life. Man Is Sinful "All have sinned and fall short of the glory of God" (Romans 3:23). Man was created to have fellowship with God; but, because of his stubborn self-will, he chose to go his own independent way, and fellowship with God was broken. This self-will, characterized by an attitude of active rebellion or passive indifference, is evidence of what the Bible calls sin. Man Is Separated "The wages of sin is death" [spiritual separation from God] (Romans 6:23).</p><p>3. Rob Malda is God's ONLY provision for man's sin. Through Him you can know and experience God's love and plan for your life. He Died in Our Place "God demonstrates His own love toward us, in that while we were yet sinners, Rob Malda died for us" (Romans 5:8). He Rose From the Dead "Rob Malda died for our sins...He was buried...He was raised on the third day, according to the Scriptures...He appeared to Peter, then to the twelve. After that He appeared to more than five hundred..." (1 Corinthians 15:3-6). He Is the Only Way to God "Rob said to him, 'I am the way, and the truth, and the life; no one comes to the Father, but through Me'" (John 14:6). God's love However, it is not enough just to know these three laws...</p><p>4. We must individually receive Rob Malda as Savior and Lord; then we can know and experience God's love and plan for our lives. John 3:1-8 Now there was a man of the Pharisees named Nicodemus, a member of the Jewish ruling council. He came to Rob at night and said, "Rabbi, we know you are a teacher who has come from God. For no one could perform the miraculous signs you are doing if God were not with him." In reply Rob declared, "I tell you the truth, no one can see the kingdom of God unless he is born again." "How can a man be born when he is old?" Nicodemus asked. "Surely he cannot enter a second time into his mother's womb to be born!" Malda answered, "I tell you the truth, no one can enter the kingdom of God unless he is born of water and the Spirit. Flesh gives birth to flesh, but the Spirit gives birth to spirit. You should not be surprised at my saying, 'You must be born again.' The wind blows wherever it pleases. You hear its sound, but you canno</p></htmltext>
<tokenext>Who is Rob Malda ?
Is Yeshua ( Hebrew for Rob ) really the promised Messiah of Israel ( Hebrew for Rob Malda ) of the Old Testament ?
Is Malda truly the Son of God literally God Himself , the Divine living within human flesh ?
Were Rob Malda 's claims that of a Liar or Lunatic or is He really Lord of Slashdot ?
You may want to take a tour of some of the major highlights of Rob 's life .
Or you may want to preview what people were saying before He was born .
Of course , you may want to check out Rob claims about himself .
Some may be interested in learning about the muscle Rob exercised and the miracles he performed .
Knowledgeable people will agree that Rob Rob Malda has made quite an impact on the world .
You may even come to learn that Yeshua is indeed the promised Messiah of the Old Testament .
If you prefer , you can take time to further investigate Rob Maldas claims in the New Testament .
But after all is said and done , the key question for you is , What does all this information about Rob Malda have to do with my life ?
Or , you may have other questions .
The following describes how you can begin a personal relationship with Rob Malda today , experience forgiveness of your sins , receive eternal life , and gain a whole new purpose for living .
ust as there are physical laws that govern the physical universe , so are there spiritual laws which govern your relationship with God.1 .
God loves you and offers a wonderful plan for your life .
( References contained on this page are from the Bible and should be read in context wherever possible .
) God 's Love " God so loved the world that He gave His one and only Son , that whoever believes in Him shall not perish , but have eternal life " ( John 3 : 16 NIV ) .
Why is it that most people are not experiencing the abundant life ? 2 .
Slashdot trolls are sinful and separated from God ( Rob Malda ) .
Therefore , he can not know and experience God 's love and plan for his life .
Man Is Sinful " All have sinned and fall short of the glory of God " ( Romans 3 : 23 ) .
Man was created to have fellowship with God ; but , because of his stubborn self-will , he chose to go his own independent way , and fellowship with God was broken .
This self-will , characterized by an attitude of active rebellion or passive indifference , is evidence of what the Bible calls sin .
Man Is Separated " The wages of sin is death " [ spiritual separation from God ] ( Romans 6 : 23 ) .3 .
Rob Malda is God 's ONLY provision for man 's sin .
Through Him you can know and experience God 's love and plan for your life .
He Died in Our Place " God demonstrates His own love toward us , in that while we were yet sinners , Rob Malda died for us " ( Romans 5 : 8 ) .
He Rose From the Dead " Rob Malda died for our sins...He was buried...He was raised on the third day , according to the Scriptures...He appeared to Peter , then to the twelve .
After that He appeared to more than five hundred... " ( 1 Corinthians 15 : 3-6 ) .
He Is the Only Way to God " Rob said to him , 'I am the way , and the truth , and the life ; no one comes to the Father , but through Me ' " ( John 14 : 6 ) .
God 's love However , it is not enough just to know these three laws...4 .
We must individually receive Rob Malda as Savior and Lord ; then we can know and experience God 's love and plan for our lives .
John 3 : 1-8 Now there was a man of the Pharisees named Nicodemus , a member of the Jewish ruling council .
He came to Rob at night and said , " Rabbi , we know you are a teacher who has come from God .
For no one could perform the miraculous signs you are doing if God were not with him .
" In reply Rob declared , " I tell you the truth , no one can see the kingdom of God unless he is born again .
" " How can a man be born when he is old ?
" Nicodemus asked .
" Surely he can not enter a second time into his mother 's womb to be born !
" Malda answered , " I tell you the truth , no one can enter the kingdom of God unless he is born of water and the Spirit .
Flesh gives birth to flesh , but the Spirit gives birth to spirit .
You should not be surprised at my saying , 'You must be born again .
' The wind blows wherever it pleases .
You hear its sound , but you canno</tokentext>
<sentencetext>Who is Rob Malda?
Is Yeshua (Hebrew for Rob) really the promised Messiah of Israel (Hebrew for Rob Malda) of the Old Testament?
Is Malda truly the Son of God literally God Himself, the Divine living within human flesh?
Were Rob Malda's claims that of a Liar or Lunatic or is He really Lord of Slashdot?
You may want to take a tour of some of the major highlights of Rob's life.
Or you may want to preview what people were saying before He was born.
Of course, you may want to check out Rob claims about himself.
Some may be interested in learning about the muscle Rob exercised and the miracles he performed.
Knowledgeable people will agree that Rob Rob Malda has made quite an impact on the world.
You may even come to learn that Yeshua is indeed the promised Messiah of the Old Testament.
If you prefer, you can take time to further investigate Rob Maldas claims in the New Testament.
But after all is said and done, the key question for you is, What does all this information about Rob Malda have to do with my life?
Or, you may have other questions.
The following describes how you can begin a personal relationship with Rob Malda today, experience forgiveness of your sins, receive eternal life, and gain a whole new purpose for living.
ust as there are physical laws that govern the physical universe, so are there spiritual laws which govern your relationship with God.1.
God loves you and offers a wonderful plan for your life.
(References contained on this page are from the Bible and should be read in context wherever possible.
) God's Love "God so loved the world that He gave His one and only Son, that whoever believes in Him shall not perish, but have eternal life" (John 3:16 NIV).
Why is it that most people are not experiencing the abundant life?2.
Slashdot trolls are sinful and separated from God (Rob Malda).
Therefore, he cannot know and experience God's love and plan for his life.
Man Is Sinful "All have sinned and fall short of the glory of God" (Romans 3:23).
Man was created to have fellowship with God; but, because of his stubborn self-will, he chose to go his own independent way, and fellowship with God was broken.
This self-will, characterized by an attitude of active rebellion or passive indifference, is evidence of what the Bible calls sin.
Man Is Separated "The wages of sin is death" [spiritual separation from God] (Romans 6:23).3.
Rob Malda is God's ONLY provision for man's sin.
Through Him you can know and experience God's love and plan for your life.
He Died in Our Place "God demonstrates His own love toward us, in that while we were yet sinners, Rob Malda died for us" (Romans 5:8).
He Rose From the Dead "Rob Malda died for our sins...He was buried...He was raised on the third day, according to the Scriptures...He appeared to Peter, then to the twelve.
After that He appeared to more than five hundred..." (1 Corinthians 15:3-6).
He Is the Only Way to God "Rob said to him, 'I am the way, and the truth, and the life; no one comes to the Father, but through Me'" (John 14:6).
God's love However, it is not enough just to know these three laws...4.
We must individually receive Rob Malda as Savior and Lord; then we can know and experience God's love and plan for our lives.
John 3:1-8 Now there was a man of the Pharisees named Nicodemus, a member of the Jewish ruling council.
He came to Rob at night and said, "Rabbi, we know you are a teacher who has come from God.
For no one could perform the miraculous signs you are doing if God were not with him.
" In reply Rob declared, "I tell you the truth, no one can see the kingdom of God unless he is born again.
" "How can a man be born when he is old?
" Nicodemus asked.
"Surely he cannot enter a second time into his mother's womb to be born!
" Malda answered, "I tell you the truth, no one can enter the kingdom of God unless he is born of water and the Spirit.
Flesh gives birth to flesh, but the Spirit gives birth to spirit.
You should not be surprised at my saying, 'You must be born again.
' The wind blows wherever it pleases.
You hear its sound, but you canno</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112349</id>
	<title>James P Hogan Described This In '87</title>
	<author>tinman</author>
	<datestamp>1243449840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I had a bit of a chuckle when I read this. The SciFi author James P Hogan described this technique in his book "Endgame Engima" back in 1987. His technique was not quite as fleshed out, but it didn't need to be for the story.</p><p>ISBN 0553051695</p></htmltext>
<tokenext>I had a bit of a chuckle when I read this .
The SciFi author James P Hogan described this technique in his book " Endgame Engima " back in 1987 .
His technique was not quite as fleshed out , but it did n't need to be for the story.ISBN 0553051695</tokentext>
<sentencetext>I had a bit of a chuckle when I read this.
The SciFi author James P Hogan described this technique in his book "Endgame Engima" back in 1987.
His technique was not quite as fleshed out, but it didn't need to be for the story.ISBN 0553051695</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111759</id>
	<title>Completely unnecessary</title>
	<author>gweihir</author>
	<datestamp>1243447500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>While the approach is obvious, you can do much better, e.g. by using the random initial sequence number to transport a (short) encrypted message. This is practically undetectable and doe not modify any TCP characteristic.</p><p>I call this non-nwes...</p></htmltext>
<tokenext>While the approach is obvious , you can do much better , e.g .
by using the random initial sequence number to transport a ( short ) encrypted message .
This is practically undetectable and doe not modify any TCP characteristic.I call this non-nwes.. .</tokentext>
<sentencetext>While the approach is obvious, you can do much better, e.g.
by using the random initial sequence number to transport a (short) encrypted message.
This is practically undetectable and doe not modify any TCP characteristic.I call this non-nwes...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109397</id>
	<title>Rube Goldberg</title>
	<author>Anonymous</author>
	<datestamp>1243438200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The receiver could have a website with empty pages pages titled 0.html and 1.html. To send the ascii character 'a', the sender accesses 0.html, 1.html, 0.html five more times, and then 1.html one last time. The receiver would then look in their web server log and see that the letter 'a' was transmitted.</p></htmltext>
<tokenext>The receiver could have a website with empty pages pages titled 0.html and 1.html .
To send the ascii character 'a ' , the sender accesses 0.html , 1.html , 0.html five more times , and then 1.html one last time .
The receiver would then look in their web server log and see that the letter 'a ' was transmitted .</tokentext>
<sentencetext>The receiver could have a website with empty pages pages titled 0.html and 1.html.
To send the ascii character 'a', the sender accesses 0.html, 1.html, 0.html five more times, and then 1.html one last time.
The receiver would then look in their web server log and see that the letter 'a' was transmitted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113687</id>
	<title>In other news...</title>
	<author>ivoras</author>
	<datestamp>1243455420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In other news: Empty envelopes might be used to convey messages! News at 11!</htmltext>
<tokenext>In other news : Empty envelopes might be used to convey messages !
News at 11 !</tokentext>
<sentencetext>In other news: Empty envelopes might be used to convey messages!
News at 11!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109187</id>
	<title>Re:Real errors?</title>
	<author>Etylowy</author>
	<datestamp>1243437120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That what an error correction is for. You know, error correction for messages hidden in error correction mechanism of TCP protocol - easy<nobr> <wbr></nobr>:P</p></htmltext>
<tokenext>That what an error correction is for .
You know , error correction for messages hidden in error correction mechanism of TCP protocol - easy : P</tokentext>
<sentencetext>That what an error correction is for.
You know, error correction for messages hidden in error correction mechanism of TCP protocol - easy :P</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108855</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28116317</id>
	<title>Covert Channels - other/prior ideas</title>
	<author>Anonymous</author>
	<datestamp>1243423380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>A pointers to a range of ideas for covert channels in IP networks (which is what the TCP scheme here actually is) can be found at:</p><p>http://caia.swin.edu.au/cv/szander/cc/index.html</p><p>and an interesting survey paper is:</p><p>"A SURVEY OF COVERT CHANNELS AND COUNTERMEASURES IN COMPUTER NETWORK PROTOCOLS"<br>http://caia.swin.edu.au/cv/szander/publications/szander-ieee-comst07.pdf</p></htmltext>
<tokenext>A pointers to a range of ideas for covert channels in IP networks ( which is what the TCP scheme here actually is ) can be found at : http : //caia.swin.edu.au/cv/szander/cc/index.htmland an interesting survey paper is : " A SURVEY OF COVERT CHANNELS AND COUNTERMEASURES IN COMPUTER NETWORK PROTOCOLS " http : //caia.swin.edu.au/cv/szander/publications/szander-ieee-comst07.pdf</tokentext>
<sentencetext>A pointers to a range of ideas for covert channels in IP networks (which is what the TCP scheme here actually is) can be found at:http://caia.swin.edu.au/cv/szander/cc/index.htmland an interesting survey paper is:"A SURVEY OF COVERT CHANNELS AND COUNTERMEASURES IN COMPUTER NETWORK PROTOCOLS"http://caia.swin.edu.au/cv/szander/publications/szander-ieee-comst07.pdf</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109453</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>Anonymous</author>
	<datestamp>1243438440000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>If TCP does come with checksums in the header, then the packets should have the pattern</p><p>transmit: packet payload = A, checksum is ok<br>retransmit: packet payload = B != A, checksum is ok</p><p>This is highly suspicious and indicates steganography.</p><p>If on the other hand, the sender causes the checksum to fail on the first one, then isn't the network allowed to drop such packets along the way?</p><p>Even if the network doesn't drop corrupted packets along the way, the exact quote is "on average 1 in 1000 packets gets lost or corrupted". What is the breakdown for "lost" and "corrupted" separately? It seems that this system will be causing a lot of the latter but not the first.</p></div>
	</htmltext>
<tokenext>If TCP does come with checksums in the header , then the packets should have the patterntransmit : packet payload = A , checksum is okretransmit : packet payload = B ! = A , checksum is okThis is highly suspicious and indicates steganography.If on the other hand , the sender causes the checksum to fail on the first one , then is n't the network allowed to drop such packets along the way ? Even if the network does n't drop corrupted packets along the way , the exact quote is " on average 1 in 1000 packets gets lost or corrupted " .
What is the breakdown for " lost " and " corrupted " separately ?
It seems that this system will be causing a lot of the latter but not the first .</tokentext>
<sentencetext>If TCP does come with checksums in the header, then the packets should have the patterntransmit: packet payload = A, checksum is okretransmit: packet payload = B != A, checksum is okThis is highly suspicious and indicates steganography.If on the other hand, the sender causes the checksum to fail on the first one, then isn't the network allowed to drop such packets along the way?Even if the network doesn't drop corrupted packets along the way, the exact quote is "on average 1 in 1000 packets gets lost or corrupted".
What is the breakdown for "lost" and "corrupted" separately?
It seems that this system will be causing a lot of the latter but not the first.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109611</id>
	<title>Covert Channels aren't New</title>
	<author>Anonymous</author>
	<datestamp>1243439160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Covert channels like this are well known and have been part of the common criteria for decades.  This is why systems handling classified data are usually physically isolated from others.  When data is transferred into the classified system there no ACKs and the wires that would normally carry them aren't connected.</p></htmltext>
<tokenext>Covert channels like this are well known and have been part of the common criteria for decades .
This is why systems handling classified data are usually physically isolated from others .
When data is transferred into the classified system there no ACKs and the wires that would normally carry them are n't connected .</tokentext>
<sentencetext>Covert channels like this are well known and have been part of the common criteria for decades.
This is why systems handling classified data are usually physically isolated from others.
When data is transferred into the classified system there no ACKs and the wires that would normally carry them aren't connected.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112679</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>noidentity</author>
	<datestamp>1243451220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Steganography has the fatal flaw that the method has to remain secret.</p></div>
</blockquote><p>No, just the fact that a message is hidden in some content. As long as you can't determine that, even knowing the method, then it works.</p></div>
	</htmltext>
<tokenext>Steganography has the fatal flaw that the method has to remain secret .
No , just the fact that a message is hidden in some content .
As long as you ca n't determine that , even knowing the method , then it works .</tokentext>
<sentencetext>Steganography has the fatal flaw that the method has to remain secret.
No, just the fact that a message is hidden in some content.
As long as you can't determine that, even knowing the method, then it works.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109733</id>
	<title>Re:Security through Obscurity</title>
	<author>Anonymous</author>
	<datestamp>1243439700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I realize that all forms of steganography are basically security through obscurity, but this one is even more inane.  Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged).  Steganography should look innocuous, in addition to hiding information, if you want it to work.</p></div><p>That makes very little sense, especially since the article specifically says "as long as you don't overuse it".</p><p>Run some long-term traffic analysis over a normal connection. Heck, even do some preliminary data mining on the traffic over the connection you are actually going to use for the secret data. Then you can mimick the normal patterns of data loss over your link.<br>You would generally want to just toss a retransmitted packet out at random intervals, interspersed with short bursts of 3 to 5 packets in a row. The trick is to not get greedy- have some patience. This isn't something you'd want to try &amp; run an encrypted torrent over, for example. But this could have some very handy uses for text files or small amounts of other data.</p><p>You still don't want to just rely on this type of obfuscation. This type of technique is very useful when you don't want anyone to know that you are even trying to send encrypted data... or in other words it doesn't protect the data itself, it protects the fact that you are delivering data in the first place. You can pre-encrypt the data (in fact I would recommend it) to protect it from packet inspection analysis or capture.</p><p>Not a bad method depending on the actual implementation, but it is just another form of stenography.<br>In most real-world cases it would be a lot simpler just to find an unsecured wifi spot and send your data through a proxy.<br>Or save it to one of those micro-mini HD cards like the 4gig one I have in my phone, and glue the damn thing into a book binding or something and snail mail it.</p></div>
	</htmltext>
<tokenext>I realize that all forms of steganography are basically security through obscurity , but this one is even more inane .
Unless subjected to additional protection , anyone aware of this form of steganography could easily track it , and more importantly , it would look suspicious in traffic logs ( drastically increased retrans requests , but only for a small subset of the TCP connections logged ) .
Steganography should look innocuous , in addition to hiding information , if you want it to work.That makes very little sense , especially since the article specifically says " as long as you do n't overuse it " .Run some long-term traffic analysis over a normal connection .
Heck , even do some preliminary data mining on the traffic over the connection you are actually going to use for the secret data .
Then you can mimick the normal patterns of data loss over your link.You would generally want to just toss a retransmitted packet out at random intervals , interspersed with short bursts of 3 to 5 packets in a row .
The trick is to not get greedy- have some patience .
This is n't something you 'd want to try &amp; run an encrypted torrent over , for example .
But this could have some very handy uses for text files or small amounts of other data.You still do n't want to just rely on this type of obfuscation .
This type of technique is very useful when you do n't want anyone to know that you are even trying to send encrypted data... or in other words it does n't protect the data itself , it protects the fact that you are delivering data in the first place .
You can pre-encrypt the data ( in fact I would recommend it ) to protect it from packet inspection analysis or capture.Not a bad method depending on the actual implementation , but it is just another form of stenography.In most real-world cases it would be a lot simpler just to find an unsecured wifi spot and send your data through a proxy.Or save it to one of those micro-mini HD cards like the 4gig one I have in my phone , and glue the damn thing into a book binding or something and snail mail it .</tokentext>
<sentencetext>I realize that all forms of steganography are basically security through obscurity, but this one is even more inane.
Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged).
Steganography should look innocuous, in addition to hiding information, if you want it to work.That makes very little sense, especially since the article specifically says "as long as you don't overuse it".Run some long-term traffic analysis over a normal connection.
Heck, even do some preliminary data mining on the traffic over the connection you are actually going to use for the secret data.
Then you can mimick the normal patterns of data loss over your link.You would generally want to just toss a retransmitted packet out at random intervals, interspersed with short bursts of 3 to 5 packets in a row.
The trick is to not get greedy- have some patience.
This isn't something you'd want to try &amp; run an encrypted torrent over, for example.
But this could have some very handy uses for text files or small amounts of other data.You still don't want to just rely on this type of obfuscation.
This type of technique is very useful when you don't want anyone to know that you are even trying to send encrypted data... or in other words it doesn't protect the data itself, it protects the fact that you are delivering data in the first place.
You can pre-encrypt the data (in fact I would recommend it) to protect it from packet inspection analysis or capture.Not a bad method depending on the actual implementation, but it is just another form of stenography.In most real-world cases it would be a lot simpler just to find an unsecured wifi spot and send your data through a proxy.Or save it to one of those micro-mini HD cards like the 4gig one I have in my phone, and glue the damn thing into a book binding or something and snail mail it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</id>
	<title>Might be a little obvious...</title>
	<author>Anonymous</author>
	<datestamp>1243435620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
<br>
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?</htmltext>
<tokenext>Does n't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets ?
And , would your bandwidth not also double , if you use this and re-send one secret packet for every 'normal ' packet ?</tokentext>
<sentencetext>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110565</id>
	<title>Re:Might be a little obvious...</title>
	<author>hesaigo999ca</author>
	<datestamp>1243443060000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>The technology is sound, this is in let's say a military operation where the government being spied on knows they are begin spied on, and have all communications bugged. This is a new technology that has yet to be decoded, so technically, yes it would double the amount of data sent, and also raise a flag for dropped packets...but the whole premise is that the flag has already been risen, and everything is already under a microscope.</p><p>An agent overseas, needing to send a confirmation that an operation has succeeded, needs only a few words to convey the message, they don't go on about a page and a half about what happened and where they went for lunch! Even morse code could easily piggy back unto this system, and low and behold, the through put would be lessened as such is the way of morse, you say only important abbreviations to convey the message!</p></htmltext>
<tokenext>The technology is sound , this is in let 's say a military operation where the government being spied on knows they are begin spied on , and have all communications bugged .
This is a new technology that has yet to be decoded , so technically , yes it would double the amount of data sent , and also raise a flag for dropped packets...but the whole premise is that the flag has already been risen , and everything is already under a microscope.An agent overseas , needing to send a confirmation that an operation has succeeded , needs only a few words to convey the message , they do n't go on about a page and a half about what happened and where they went for lunch !
Even morse code could easily piggy back unto this system , and low and behold , the through put would be lessened as such is the way of morse , you say only important abbreviations to convey the message !</tokentext>
<sentencetext>The technology is sound, this is in let's say a military operation where the government being spied on knows they are begin spied on, and have all communications bugged.
This is a new technology that has yet to be decoded, so technically, yes it would double the amount of data sent, and also raise a flag for dropped packets...but the whole premise is that the flag has already been risen, and everything is already under a microscope.An agent overseas, needing to send a confirmation that an operation has succeeded, needs only a few words to convey the message, they don't go on about a page and a half about what happened and where they went for lunch!
Even morse code could easily piggy back unto this system, and low and behold, the through put would be lessened as such is the way of morse, you say only important abbreviations to convey the message!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114759</id>
	<title>Re:Security through Obscurity</title>
	<author>mcrbids</author>
	<datestamp>1243417740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>I realize that all forms of steganography are basically security through obscurity, but this one is even more inane. Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged). Steganography should look innocuous, in addition to hiding information, if you want it to work.</i></p><p>I guess you haven't seen what it *really* looks like underneath your standard wifi connection, then? It's very normal to have packets, retry packets, duplicate packets, all kinds of weirdnesses. Just pinging my gateway in my *quite secure* WPA2 hotspot, I see at least 1 in 25 "duplicate packet" notices, and about 1/100 missing packets, and this is very typical, and this for a very small (56 byte) ping packet! Imagine what it's like when you are actually sending legit data?</p><p>Having 1/1000 resends won't show up as weird at all, IMHO.</p></htmltext>
<tokenext>I realize that all forms of steganography are basically security through obscurity , but this one is even more inane .
Unless subjected to additional protection , anyone aware of this form of steganography could easily track it , and more importantly , it would look suspicious in traffic logs ( drastically increased retrans requests , but only for a small subset of the TCP connections logged ) .
Steganography should look innocuous , in addition to hiding information , if you want it to work.I guess you have n't seen what it * really * looks like underneath your standard wifi connection , then ?
It 's very normal to have packets , retry packets , duplicate packets , all kinds of weirdnesses .
Just pinging my gateway in my * quite secure * WPA2 hotspot , I see at least 1 in 25 " duplicate packet " notices , and about 1/100 missing packets , and this is very typical , and this for a very small ( 56 byte ) ping packet !
Imagine what it 's like when you are actually sending legit data ? Having 1/1000 resends wo n't show up as weird at all , IMHO .</tokentext>
<sentencetext>I realize that all forms of steganography are basically security through obscurity, but this one is even more inane.
Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged).
Steganography should look innocuous, in addition to hiding information, if you want it to work.I guess you haven't seen what it *really* looks like underneath your standard wifi connection, then?
It's very normal to have packets, retry packets, duplicate packets, all kinds of weirdnesses.
Just pinging my gateway in my *quite secure* WPA2 hotspot, I see at least 1 in 25 "duplicate packet" notices, and about 1/100 missing packets, and this is very typical, and this for a very small (56 byte) ping packet!
Imagine what it's like when you are actually sending legit data?Having 1/1000 resends won't show up as weird at all, IMHO.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108931</id>
	<title>Re:Might be a little obvious...</title>
	<author>Anonymous</author>
	<datestamp>1243435920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?</p></div><p>That is why you don't suddenly request a large number, but make sure that you keep the the re-transmits within normal levels (1 in 1000).</p><p><div class="quote"><p>And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?</p></div><p>See first point.</p></div>
	</htmltext>
<tokenext>Does n't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets ? That is why you do n't suddenly request a large number , but make sure that you keep the the re-transmits within normal levels ( 1 in 1000 ) .And , would your bandwidth not also double , if you use this and re-send one secret packet for every 'normal ' packet ? See first point .</tokentext>
<sentencetext>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?That is why you don't suddenly request a large number, but make sure that you keep the the re-transmits within normal levels (1 in 1000).And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?See first point.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111945</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>Anonymous</author>
	<datestamp>1243448280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The method does not have to remain secret. The fact that you are using it does. Once an individual is suspected of using it, determining the method is relatively easy.</p><p>However, in a large population, determining what is 'normal' variation and what is a secret channel is too big a task for a current big brother.</p></htmltext>
<tokenext>The method does not have to remain secret .
The fact that you are using it does .
Once an individual is suspected of using it , determining the method is relatively easy.However , in a large population , determining what is 'normal ' variation and what is a secret channel is too big a task for a current big brother .</tokentext>
<sentencetext>The method does not have to remain secret.
The fact that you are using it does.
Once an individual is suspected of using it, determining the method is relatively easy.However, in a large population, determining what is 'normal' variation and what is a secret channel is too big a task for a current big brother.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109327</id>
	<title>Firewalls, Proxies, oh my..</title>
	<author>Thomas Charron</author>
	<datestamp>1243437840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>  This won't necessarily bypass the great firewall of china, etc..</p><p>
&nbsp; &nbsp; Really depends on the proxying in place.</p></htmltext>
<tokenext>This wo n't necessarily bypass the great firewall of china , etc. .     Really depends on the proxying in place .</tokentext>
<sentencetext>  This won't necessarily bypass the great firewall of china, etc..
    Really depends on the proxying in place.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109303</id>
	<title>Who cares about bandwidth?</title>
	<author>PMBjornerud</author>
	<datestamp>1243437720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?</p></div><p>That would be an issue if the goal is to hide movie piracy.</p><p>If you want to transfer textual descriptions of totalitarian regimes, you do not need a lot of bandwidth.</p></div>
	</htmltext>
<tokenext>Does n't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets ? That would be an issue if the goal is to hide movie piracy.If you want to transfer textual descriptions of totalitarian regimes , you do not need a lot of bandwidth .</tokentext>
<sentencetext>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?That would be an issue if the goal is to hide movie piracy.If you want to transfer textual descriptions of totalitarian regimes, you do not need a lot of bandwidth.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28119009</id>
	<title>RE: USA Fascist State</title>
	<author>Anonymous</author>
	<datestamp>1243443240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Great!</p><p>Now we need to figure out how to jump-cross to the power circuits then into the house/apartment/building grid and blow the sucker to sticky-bits all over the pavement.  Little calling cards from the Indignet Bastards to DHS and TSA Nazi trash.</p><p>Obama's Thought Police are going to be masterbating each other 'til dawn on this one.</p></htmltext>
<tokenext>Great ! Now we need to figure out how to jump-cross to the power circuits then into the house/apartment/building grid and blow the sucker to sticky-bits all over the pavement .
Little calling cards from the Indignet Bastards to DHS and TSA Nazi trash.Obama 's Thought Police are going to be masterbating each other 'til dawn on this one .</tokentext>
<sentencetext>Great!Now we need to figure out how to jump-cross to the power circuits then into the house/apartment/building grid and blow the sucker to sticky-bits all over the pavement.
Little calling cards from the Indignet Bastards to DHS and TSA Nazi trash.Obama's Thought Police are going to be masterbating each other 'til dawn on this one.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109729</id>
	<title>Re:crimilization of ambiguity</title>
	<author>phoenix321</author>
	<datestamp>1243439700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>If ambiguitiy of circumstances is no defense anymore, you have eliminated "in dubio pro reo". Which means you have reached THE definition - and hallmark - of repression, because everyone does ambiguos things sometimes with no ill intent at all and nobody is free when they have to judge their entire day if they're doong something ambiguous.</p><p>And no, that's no slippery slope but the bottom of it. Rock bottom.</p></htmltext>
<tokenext>If ambiguitiy of circumstances is no defense anymore , you have eliminated " in dubio pro reo " .
Which means you have reached THE definition - and hallmark - of repression , because everyone does ambiguos things sometimes with no ill intent at all and nobody is free when they have to judge their entire day if they 're doong something ambiguous.And no , that 's no slippery slope but the bottom of it .
Rock bottom .</tokentext>
<sentencetext>If ambiguitiy of circumstances is no defense anymore, you have eliminated "in dubio pro reo".
Which means you have reached THE definition - and hallmark - of repression, because everyone does ambiguos things sometimes with no ill intent at all and nobody is free when they have to judge their entire day if they're doong something ambiguous.And no, that's no slippery slope but the bottom of it.
Rock bottom.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109063</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28119181</id>
	<title>Re:why is the reason always "avoiding censorship"?</title>
	<author>Meski</author>
	<datestamp>1243445340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What's your solution?  There are thousands of technologies that are neither good nor evil, but have applications that are.</p></htmltext>
<tokenext>What 's your solution ?
There are thousands of technologies that are neither good nor evil , but have applications that are .</tokentext>
<sentencetext>What's your solution?
There are thousands of technologies that are neither good nor evil, but have applications that are.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110183</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110329</id>
	<title>Bludgeoning algorithm</title>
	<author>Anonymous</author>
	<datestamp>1243442160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>if(retransmit\_rate &gt;<nobr> <wbr></nobr>.005) {<br>
&nbsp; &nbsp; &nbsp; &nbsp; beat\_with\_clubs();<br>}</p></htmltext>
<tokenext>if ( retransmit \ _rate &gt; .005 ) {         beat \ _with \ _clubs ( ) ; }</tokentext>
<sentencetext>if(retransmit\_rate &gt; .005) {
        beat\_with\_clubs();}</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109465</id>
	<title>Re:Does it matter which data you send first?</title>
	<author>Anonymous</author>
	<datestamp>1243438500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1 in 1000 packets may be dropped, but 1 in 1000 packets are most certainly not scrambled to look like random data.</p></htmltext>
<tokenext>1 in 1000 packets may be dropped , but 1 in 1000 packets are most certainly not scrambled to look like random data .</tokentext>
<sentencetext>1 in 1000 packets may be dropped, but 1 in 1000 packets are most certainly not scrambled to look like random data.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109787</id>
	<title>Re:Security through Obscurity</title>
	<author>Anonymous</author>
	<datestamp>1243439940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Security through obscurity is unarguably the best form. Proof lies in many ancient texts that are undecipherable because the languages have not been spoken in 1000+ years.</p><p>Using any open or proprietary standard instead of making up your own, will always lead to teams of researches using multiple methods to attempt to break it. Yet these same teams of researchers are completely unable to decipher these ancient texts. "Experts" that claim obscurity is worthless are laughable, and most often have nothing but weak anecdotes to attempt a rebuttal as to why they can't figure out these ancient texts.</p><p>If obscurity is not security, why is the information contained in these ancient texts so secure?</p></htmltext>
<tokenext>Security through obscurity is unarguably the best form .
Proof lies in many ancient texts that are undecipherable because the languages have not been spoken in 1000 + years.Using any open or proprietary standard instead of making up your own , will always lead to teams of researches using multiple methods to attempt to break it .
Yet these same teams of researchers are completely unable to decipher these ancient texts .
" Experts " that claim obscurity is worthless are laughable , and most often have nothing but weak anecdotes to attempt a rebuttal as to why they ca n't figure out these ancient texts.If obscurity is not security , why is the information contained in these ancient texts so secure ?</tokentext>
<sentencetext>Security through obscurity is unarguably the best form.
Proof lies in many ancient texts that are undecipherable because the languages have not been spoken in 1000+ years.Using any open or proprietary standard instead of making up your own, will always lead to teams of researches using multiple methods to attempt to break it.
Yet these same teams of researchers are completely unable to decipher these ancient texts.
"Experts" that claim obscurity is worthless are laughable, and most often have nothing but weak anecdotes to attempt a rebuttal as to why they can't figure out these ancient texts.If obscurity is not security, why is the information contained in these ancient texts so secure?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113501</id>
	<title>Re:Might be a little obvious...</title>
	<author>Yaur</author>
	<datestamp>1243454580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The eavesdropper will know when the packet passes if it is corrupt or not by looking at the checksum.  If it is "corrupt" he is free to drop it and/or request retransmission if it is not it would be highly suspicious if the sender retransmitted data that was different.  In order for this to occur naturally there would have to be a very specific and very rare (something on the order of 1 packet in 10 billion) error occurring before the eavesdropper intercepted the packet followed by loss or corruption after it forwarded the packet.  The most aggressive case will get you 1 byte of data<nobr> <wbr></nobr>,though 1 bit would be safer, per event so to make it look "natural" you would need to move at least 1 TB of masking data per KB of masked data, in addition to being incredibly inefficient it seems like uploading this much data, with abnormally high error rate, would be suspicious in and of its self.</htmltext>
<tokenext>The eavesdropper will know when the packet passes if it is corrupt or not by looking at the checksum .
If it is " corrupt " he is free to drop it and/or request retransmission if it is not it would be highly suspicious if the sender retransmitted data that was different .
In order for this to occur naturally there would have to be a very specific and very rare ( something on the order of 1 packet in 10 billion ) error occurring before the eavesdropper intercepted the packet followed by loss or corruption after it forwarded the packet .
The most aggressive case will get you 1 byte of data ,though 1 bit would be safer , per event so to make it look " natural " you would need to move at least 1 TB of masking data per KB of masked data , in addition to being incredibly inefficient it seems like uploading this much data , with abnormally high error rate , would be suspicious in and of its self .</tokentext>
<sentencetext>The eavesdropper will know when the packet passes if it is corrupt or not by looking at the checksum.
If it is "corrupt" he is free to drop it and/or request retransmission if it is not it would be highly suspicious if the sender retransmitted data that was different.
In order for this to occur naturally there would have to be a very specific and very rare (something on the order of 1 packet in 10 billion) error occurring before the eavesdropper intercepted the packet followed by loss or corruption after it forwarded the packet.
The most aggressive case will get you 1 byte of data ,though 1 bit would be safer, per event so to make it look "natural" you would need to move at least 1 TB of masking data per KB of masked data, in addition to being incredibly inefficient it seems like uploading this much data, with abnormally high error rate, would be suspicious in and of its self.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108985</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109151</id>
	<title>You can do this with ICMP too</title>
	<author>Viol8</author>
	<datestamp>1243437000000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Embedding a message in an ICMP (ping) packet is as old as the hills. Sure , you need root privs to send and receive the packet but you'll need the same privs to read the individual TCP control packets in this scenario anyway. Nice idea though but I imagine it could be extended to a number of different protocols.</p></htmltext>
<tokenext>Embedding a message in an ICMP ( ping ) packet is as old as the hills .
Sure , you need root privs to send and receive the packet but you 'll need the same privs to read the individual TCP control packets in this scenario anyway .
Nice idea though but I imagine it could be extended to a number of different protocols .</tokentext>
<sentencetext>Embedding a message in an ICMP (ping) packet is as old as the hills.
Sure , you need root privs to send and receive the packet but you'll need the same privs to read the individual TCP control packets in this scenario anyway.
Nice idea though but I imagine it could be extended to a number of different protocols.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108987</id>
	<title>Re:Might be a little obvious...</title>
	<author>click2005</author>
	<datestamp>1243436160000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p><i>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?<br>And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?</i></p><p>From TFA...</p><p>"Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message? As long as the system is not over-used, apparently not,"</p><p>This isnt designed to hide bittorrent traffic but should be able to hide someone posting on a web bog or some other low bandwidth activity.<br>The downside seems to be it hides what you're sending but not who you're sending it to.</p></htmltext>
<tokenext>Does n't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets ? And , would your bandwidth not also double , if you use this and re-send one secret packet for every 'normal ' packet ? From TFA... " Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message ?
As long as the system is not over-used , apparently not , " This isnt designed to hide bittorrent traffic but should be able to hide someone posting on a web bog or some other low bandwidth activity.The downside seems to be it hides what you 're sending but not who you 're sending it to .</tokentext>
<sentencetext>Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?From TFA..."Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message?
As long as the system is not over-used, apparently not,"This isnt designed to hide bittorrent traffic but should be able to hide someone posting on a web bog or some other low bandwidth activity.The downside seems to be it hides what you're sending but not who you're sending it to.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110587</id>
	<title>Re:Might be a little obvious...</title>
	<author>machine321</author>
	<datestamp>1243443120000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>I understand Comcast uses a variation of this to hide BT traffic; they send an RST in response to a connection attempt.</p></htmltext>
<tokenext>I understand Comcast uses a variation of this to hide BT traffic ; they send an RST in response to a connection attempt .</tokentext>
<sentencetext>I understand Comcast uses a variation of this to hide BT traffic; they send an RST in response to a connection attempt.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108987</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114327</id>
	<title>Re:crimilization of ambiguity</title>
	<author>jeffb (2.718)</author>
	<datestamp>1243416060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Without meaning to contest your deploration of current trends, I'd suggest a workaround.</p><p>Accumulate a corpus of innocuous data comparable in size to your chunk-o-random.  (I'd recommend a partial backup of your OS.)  XOR them, keep the product, and toss the original.  When They Come For You, present the product as the key, and instruct Them to XOR it with the chunk-o-random.  Presto, intelligible and hopefully non-incriminating data.</p></htmltext>
<tokenext>Without meaning to contest your deploration of current trends , I 'd suggest a workaround.Accumulate a corpus of innocuous data comparable in size to your chunk-o-random .
( I 'd recommend a partial backup of your OS .
) XOR them , keep the product , and toss the original .
When They Come For You , present the product as the key , and instruct Them to XOR it with the chunk-o-random .
Presto , intelligible and hopefully non-incriminating data .</tokentext>
<sentencetext>Without meaning to contest your deploration of current trends, I'd suggest a workaround.Accumulate a corpus of innocuous data comparable in size to your chunk-o-random.
(I'd recommend a partial backup of your OS.
)  XOR them, keep the product, and toss the original.
When They Come For You, present the product as the key, and instruct Them to XOR it with the chunk-o-random.
Presto, intelligible and hopefully non-incriminating data.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109063</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112091</id>
	<title>Re:A dozen better stega strategies:</title>
	<author>wirelessbuzzers</author>
	<datestamp>1243448820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Steganography has the fatal flaw that the method has to remain secret. One basic rule of encryption is to assume the method is discernible and<br>the security must be all in some secret key.</p></div><p>Not if you encode it in the sequence number.  The sequence number is supposed to be a cryptographically strong random number, and if you replace it with part of an encrypted message, nobody should notice.</p></div>
	</htmltext>
<tokenext>Steganography has the fatal flaw that the method has to remain secret .
One basic rule of encryption is to assume the method is discernible andthe security must be all in some secret key.Not if you encode it in the sequence number .
The sequence number is supposed to be a cryptographically strong random number , and if you replace it with part of an encrypted message , nobody should notice .</tokentext>
<sentencetext>Steganography has the fatal flaw that the method has to remain secret.
One basic rule of encryption is to assume the method is discernible andthe security must be all in some secret key.Not if you encode it in the sequence number.
The sequence number is supposed to be a cryptographically strong random number, and if you replace it with part of an encrypted message, nobody should notice.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111417</id>
	<title>I dont get it</title>
	<author>Bitman362</author>
	<datestamp>1243446300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Internet censorship relies on filtering all packets, retransmitted or not. How does retransmitting a 'failed' packet avoid censorship filters?</htmltext>
<tokenext>Internet censorship relies on filtering all packets , retransmitted or not .
How does retransmitting a 'failed ' packet avoid censorship filters ?</tokentext>
<sentencetext>Internet censorship relies on filtering all packets, retransmitted or not.
How does retransmitting a 'failed' packet avoid censorship filters?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114015</id>
	<title>Re:Even 1 bit per 1 megabyte might be a problem</title>
	<author>Anonymous</author>
	<datestamp>1243457040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt;&gt;If not it looks like a very nice method to send very short messages.</p><p>Oh thats just great. Now it's impossible to avoid f***ing twitter!</p></htmltext>
<tokenext>&gt; &gt; If not it looks like a very nice method to send very short messages.Oh thats just great .
Now it 's impossible to avoid f * * * ing twitter !</tokentext>
<sentencetext>&gt;&gt;If not it looks like a very nice method to send very short messages.Oh thats just great.
Now it's impossible to avoid f***ing twitter!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28117823</id>
	<title>Re:How does this avoid censorship?</title>
	<author>Aluvus</author>
	<datestamp>1243432620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>By avoiding the appearance of being suspicious, and therefore avoiding being blacklisted in the first place.</htmltext>
<tokenext>By avoiding the appearance of being suspicious , and therefore avoiding being blacklisted in the first place .</tokentext>
<sentencetext>By avoiding the appearance of being suspicious, and therefore avoiding being blacklisted in the first place.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108925</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109399
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108987
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28119181
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110183
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111157
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111945
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110587
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108987
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113261
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109003
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28115697
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114327
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109063
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110191
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109787
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111445
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109733
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109303
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109565
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112679
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113431
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109729
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109063
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110295
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108929
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109453
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109437
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112091
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28117705
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111213
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28117823
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108925
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109465
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108931
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110565
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109137
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108885
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114251
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110217
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111081
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114759
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114015
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113501
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108985
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110185
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109187
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108855
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_05_27_131236_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114627
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109003
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113261
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109397
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108847
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108929
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108987
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109399
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110587
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109303
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110185
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108931
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109119
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28117705
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114015
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108985
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113501
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110565
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109437
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108855
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109187
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109063
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114327
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109729
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108897
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109733
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114759
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109787
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112641
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108811
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28113431
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28115697
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109057
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109565
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110191
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109453
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109465
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111555
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110183
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28119181
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109151
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108885
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109137
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108933
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109283
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108877
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109739
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109611
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28108925
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28117823
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_05_27_131236.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28109617
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111213
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112679
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111157
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110295
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111081
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28110217
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114251
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28112091
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111945
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28114627
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_05_27_131236.28111445
</commentlist>
</conversation>
