Phony TCP Retransmissions Can Hide Secret Messages 188
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."
Does it matter which data you send first? (Score:4, Insightful)
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?
Re:Does it matter which data you send first? (Score:5, Informative)
You send the masking data first, since the recipient is the one who controls *which* masking data they ask for a retransmit on. Then the sender retransmits the real data. If you send the real data first, you have to know which piece to ask to resend. That requires some sort of framing or similar protocol, which would make it easier to spot.
Re: (Score:3, Interesting)
If you send the real data first, you have to know which piece to ask to resend.
If you know what the encrypted data looks like, you know which packet to ask for a resend on. The sender knows what the real data looks like. The receiver must necessarily know how to deal with the encrypted data. If you send the masking data first and then ask for a resend a third party can (expensively) detect the technique by reconstructing the data and deciding yourself if the data was valid or not; if you send the real data first and then the masking data this looks more like a bad packet with a reques
Re:Does it matter which data you send first? (Score:4, Insightful)
Ummm... hopefully the stenographers have a good solid connection with no data corruption!
Re: (Score:2)
Well, the receiver would "know" to a certain extent what kind of data to expect. He could easily signal the sender that the transmission was unsuccessful (independent from TCP's error checking mechanism), by implementing his own error checking on top of TCP.
Yes, it's more overhead. But in the time of faster and faster connections being monitored tighter and tighter, it's pretty much the logical step.
Re: (Score:2, Informative)
If the masking data is sent first, the intercepting party can only be certain of what the data looked like at the time it passed through whatever hop he's listening at. Obviously, corrupted data must become corrupted at some point, and just because the data appears good when you intercept it doesn't mean that the intended recipient necessarily saw it as good when it arrived. That's not a problem.
The problem with sending the masking data first is that when the interceptor looks at the real data, it won't l
Re:Does it matter which data you send first? (Score:5, Insightful)
Re: (Score:2)
Unless the eavesdropper has already thought of this and has configured his snooping tools to keep *all* of the received packets. A good tool would, of course, also run comparisons among packets, especially those having been re-sent. If "diff" can pick out the differing bits of text from two otherwise unknown sources, why couldn't one write a similar tool that's focused on pseudo-binary data?
Re: (Score:2)
That's what I said. The real data is the encrypted message. The masking data is the unencrypted (or possibly weakly encrypted) innocuous traffic. Please see sig. P.S. Why wouldn't they capture the rejected packets? They're packets, too. In any case, see sig.
Re:Does it matter which data you send first? (Score:5, Informative)
I believe the procedure will be something like this:
Msg1: "The next character is part of a secret msg: /" --> Reciever NACK ." --> Reciever NACK
Msg2: "The next character is part of a secret msg:
Msg3: "The next character is part of a secret msg: R" --> Reciever NACK
Msg4: "The next character is part of a secret msg: o" --> Reciever NACK
Msg5: "The next character is part of a secret msg: x" --> Reciever NACK
Msg6: "The next character is part of a secret msg: {ascii null}>"
Secret msg: /.Rox
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.
It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Some people are willing to accept insanely high overhead to avoid censorship - Ever try Freenet?
But I agree - You could conceivably configure a router to just shut this down (I assume - I'm not really an IT guy). If you notice that two IPs are trying to communicate with large amounts of traffic at a 0.1% success rate, you may just block that traffic to save your network.
Re:Does it matter which data you send first? (Score:5, Insightful)
>> you'd get an insanely poor data rate
The target application is busting through mass censorship by government entities. Even the equivalent throughput of a 300baud modem is better than no connectivity at all. Heck, I bet most of the /. readers over the age of 35 spent a goodly portion of their youth msging each other on local BBs at 1200baud or less --> and we thought it was lightning speed (compared to pen n'paper over snail mail).
Re: (Score:2)
Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.
Welcome to the Atomic Cafe
login:
Re: (Score:2)
Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.
1200 connect
Welcome to the Atomic Cafe
login:
(grr. first one ate the greater than less than symbols.)
\"
/
.
can't remember the escape for angle brackets.
~
'
Re: (Score:2)
HTH HAND
Re:Does it matter which data you send first? (Score:4, Funny)
Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.
WHAT? How dare you, my mother was a saint!
Re: (Score:2)
You Catholics are too fast with thinking things .. .. the only thing he said was that your mother was making morney!
Re: (Score:2)
Re: (Score:2)
So then you just keep the bad data to a minimum, say, one substantive packet retransmit in every hundred thousand. If the information is the important thing, and you have time, you'll get what you need without alerting anyone.
Just make sure you don't have a keylogger running on the transmitting computer.
Re: (Score:2)
Yes an intermediate router can drop an obviously corrupt packet (since the destination could be corrupt it's not safe to route it), or even request its retransmission... so the packets would have to be transmitted correctly with checksums intact and your detection method would work.
Re: (Score:2)
This detection method only works if you are monitoring at the last hop before the receiving system, since the packet can become corrupt on any hop after the current one.
Might be a little obvious... (Score:3, Insightful)
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?
Re:Might be a little obvious... (Score:5, Insightful)
They probably have another paper ready "Detecting RSTEG use through resent packets frequency statistical analysis"...
Re:Might be a little obvious... (Score:5, Informative)
They probably have another paper ready "Detecting RSTEG use through resent packets frequency statistical analysis"...
Parent is correct. arXiv is full of papers that have really poor methodology, and quite often the authors "improve" upon their earlier papers. This is also common in the field of data mining, where crap is initially packaged to look shiny and then Crap++ is sold as an improvement, all the while racking up the author's publication count. And that, unfortunately, is the currency of research in computer science.
Re: (Score:3, Funny)
So this is how "C++" got created in the first place!
Re:Might be a little obvious... (Score:5, Interesting)
I can tell you right now this research will get savaged in peer review. At my university, we were working on delaying ACKs to get a server to push the full window all at one time so a wireless device could power down between transmissions. Even though the server sent the packet and we sent the ACK, we were absolutely demolished in peer review because what we were doing wasn't proper TCP. If what we were doing isn't proper TCP even though it technically didn't violate the protocol at all, there's no way in hell this will fly.
Re: (Score:3, Insightful)
I believe this is not intented to be rfc compliant, but
rather cloak and dagger stealth message sending...
so you can't compare what you tried to accomplish
to what they offer.
Re: (Score:3, Interesting)
The reason you were likely demolished in the peer review is that by delaying the ACK, you're probably going to force the sender to retransmit the data, and w
Asymmetric bandwidth border crossings (Score:5, Interesting)
Whoever your peers were, they weren't familiar with best common practices for asymmetric bandwidth border crossings.
We did this in 1996 for the Whistle InterJet, back when the idea was relatively new, but it's now common practice. The problem is that if you have a border router with a relatively fast network inside the border and a slow connection to the Internet, with a faster connection for the router on the other side of the slow connection (e.g. for a DSLAM, for example, then what you're going to end up with is any larger transmission starving interactive traffic (for example, an update download vs. transient mail traffic, or a large file download vs. an ssh session.
The only reasonable way t deal with this situation from a bandwidth management perspective is to manage how full the buffer is on the routers on the other side of the slow connection, and that means banging the window size larger or smaller than it actually is in order to allow bandwidth control. Otherwise, your fast connection packs the router buffers full of data packets for the large transfers, and there's no room for packets not specifically related to the large data transfers, unless your router decides to do RED queueing. And that has its own performance issues (specifically, it increases the effective bandwidth delay product until it's the same as if it had been multiplied by your actual queue size divided by your high watermark at which pint you RED 50% of your incoming packets).
PS: This is why I always laugh at things like AltQ, which try to flow rate limit in order to do traffic shaping, since you can do that, but unless you adjust the window size, you're still going to pack up your router buffers with data unrelated to the flows that you wanted to prefer.
-- Terry
Re: (Score:2)
Hide it in Bittorrent traffic (Score:2)
Deliberately hide the stego resend packets in encrypted Bittorrent traffic. That would make this very hard to detect. Even if the Bittorrent communication was unencrypted, you'd need to figure out which segment of which torrent it's associated with, then calculate the checksum. Since the Bittorrent traffic is encrypted, this makes that much harder. Of course, you could spy on the traffic with your own peer, but the stego could be used to communicate only between known peers, in which case the other peer
Re: (Score:2)
Re: (Score:2)
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.
Re:Might be a little obvious... (Score:5, Insightful)
Re: (Score:2)
How can you simulate the normal failure rate? The normal failure rate is how often normal packets will need to be resent. The expected number of extra packets sent assuming you don't go over the expected number of normal packets lost would be zero. You would have to be lucky to get a failure low enough to be able to shove these extra packets into the stream and keep the same number of resends.
Re: (Score:2)
And here the "beauty" of heavily oversubscribed providers shines.
Have you ever tried what happens when you start using a provider that unscrupulously oversubscribes even worse than anyone could possible do without blushing with shame? Try using one of their subscriber lines at prime time. You'll be subject to packet loss and transmission errors, fluctuating wildly. One day is fine, next is crap, hell, one MINUTE is fine next is crap.
Re: (Score:2)
Re:Might be a little obvious... (Score:4, Informative)
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.
Re: (Score:2)
> This isnt designed to hide bittorrent traffic...
Then it is of no interest to the average Slashdotter.
Re: (Score:3, Insightful)
It's no problem that you're talking to someone from the US when you're in China.
What matters is what you're talking about.
Even 1 bit per 1 megabyte might be a problem (Score:5, Informative)
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
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.
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.
Re: (Score:2)
If you just flip single bits, you get around 13 bits of covert payload per corrupted packet, because the offset of the corrupted b
Who cares about bandwidth? (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
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 succ
Real errors? (Score:5, Interesting)
Re:Real errors? (Score:5, Insightful)
Security through Obscurity (Score:5, Insightful)
Re:Security through Obscurity (Score:5, Insightful)
Who said anything about drastically increased retrans requests? The method is meant for short messages to the effect of "Dmitry was arrested on false charges yesterday." that are hidden inside a transmission of a much larger file such as a picture.
Re: (Score:3, Insightful)
Re:Security through Obscurity (Score:4, Interesting)
Or you could just hide the message inside the picture with one of a number of different techniques
Or you could do both. Or you could do neither. Or you could put a decoy message inside the picture with shoddy obfuscation, and the real message in the TCP stream. Or you could use the message in the TCP stream to decrypt the message in the picture. Or you could completely bypass the Internet entirely and use a telephone, or radio, or written letter, or whatever else.
It's another option. Nothing more, nothing less.
and get you more data transfer capacity for the buck.
I'm not sure this is really necessary. The summary indicates that 1 in 1000 packets are normally corrupted... Which lets you put about 1KB data in a 1MB transmission... How many KB does it take to send a meaningful message? And just how much data do you want to risk if a single transmission is compromised?
Assuming you don't want others to see your message, you can't put more than a bit or two per retrans request, and even your message would require quite a lot of retrans requests, such that statistical techniques would reveal the existence (if not the content) of the message
Again, they're talking about duplicating what normally occurs - about 1 retransmission per 1000 packets. Which would not show up as anything terribly unusual statistically.
unless it was hidden in an absolutely huge transmission.
Again, just how much data do you need to transmit?
If you were to employ this technique on a website like DeviantArt or flickr you'd have plenty of data being transmitted... Plenty of room to hide a message or two.
Re:Security through Obscurity (Score:5, Funny)
64. Because that should be enough for anyone.
Re: (Score:3, Informative)
Re: (Score:2)
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 wh
Re: (Score:2)
At the risk of feeding a troll:
And as long as your security through obscurity is ensured by killing everyone who knows the protocol, I'm sure it will work out just fine. Problem is, usually you need to communicate with other people. As Ben Franklin put it, "Three can keep a secret, if two of them are dead." The reason obscurity is disdained is that if one person blabs, the whole protocol may need to be discarded, while a secure protocol, in theory, examined by countless experts, only needs to change the
lost vs corrupted (Score:3, Insightful)
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."
Re: (Score:2)
Re: (Score:2)
In fact if it's a working firewall it must. One of the primary functions of a firewall is to drop unexpected packets.
Re: (Score:2)
crimilization of ambiguity (Score:5, Interesting)
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.
Re:crimilization of ambiguity (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
You can do this with ICMP too (Score:3, Interesting)
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.
Re: (Score:2, Interesting)
Re: (Score:3, Informative)
A lot (most, probably) of firewalls will drop packets with reserved bits set to nonzero.
It's this problem that means that ECN is still not usable, many years after its introduction... the reserved bits are effectively useless.
Better if roles are reversed (Score:2)
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 t
Firewalls, Proxies, oh my.. (Score:2)
This won't necessarily bypass the great firewall of china, etc..
Really depends on the proxying in place.
Rube Goldberg (Score:2)
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.
Re: (Score:2)
Why not set up a fake vanity web page with hundreds of tiny sub-pages or photos, then check the log files.
Nothing so suspicious as 0.htm x 5, 1.htm x 2... just what appears to be normal surfing of a web site.
Covert Channels aren't New (Score:2)
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.
A dozen better stega strategies: (Score:4, Interesting)
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 and
the security must be all in some secret key.
Re: (Score:3, Interesting)
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
Re: (Score:2)
Of course, now that this method is public knowledge the communications channel is no longer concealed.
Security by obscurity never works because the truth can be probed out by an astute attacker. In this case it's no longer even obscure.
-Viz
Re: (Score:3, Interesting)
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 f
The secrecy isn't a bug... (Score:2)
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 know
Re: (Score:2)
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.
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.
My firewall does random sequence numbers (Score:3, Informative)
My firewall does random sequence numbers.
It does this to make up for a number of commercial operating systems that *don't* do random initial sequence numbers. Then it rewrites the packets as they go through the TCP stream, including the checksum, on both the way in and the way out.
This is a common method of mitigating "guessable" initial sequence numbers for older systems behind good firewalls.
-- Terry
Re: (Score:2)
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 & firewall vendors will probably not want to save the extra state per-connection (last seq# transmitt
How common are re-transmits due to corruption? (Score:2)
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
Damn, I thought this was gonna be subtle... (Score:2)
Like encoding the message in whether you request a retransmission of the packet or not.
why is the reason always "avoiding censorship"? (Score:3, Insightful)
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?
By this logic... (Score:2)
... we should also ban the terroristic device known as the "telephone" (because they can use it to coordinate their actions), the evil "postal service" (because they can send money through it), and the especially horrific "smoke signals" (highly secure because only people within range can see, dontcha know).
Sure, these techniques can help bad guys communicate. That doesn't mean they should be banned.
Re: (Score:2)
Who says they should be banned?
But at the same time - why is there always editorial commentary about the "good" some invention X will cause, when we damn well know that the "good" use probably won't be its primary user base...
Re: (Score:2)
My solution is to stop moralizing about all the good some new technique or invention will be doing, when its obvious that there is nothing inherently good about it.
If you've invented a technique to communicate in secret, then its easier for everyone to hide things. End of story.
This depends on evel gvmt not programming for it (Score:2)
... so... wouldn't it be the same just putting your data in the body of an ICMP echo message (ping)?
Sure (Score:2)
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 i
Completely unnecessary (Score:2)
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...
Pointless (Score:2)
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
In other news... (Score:2)
Re:torrents (Score:4, Informative)
Re: (Score:3, Informative)
In a deeply censored regime, there are no unblocked ports, and all traffic which looks encrypted is blocked, and perhaps illegal.
Re: (Score:2)
>>In a deeply censored regime, there are no unblocked ports, and all traffic which looks encrypted is blocked, and perhaps illegal.
I've always been curious what "regimes" these are. In China, I could go to an internet cafe and ssh back to my box in San Diego, and if they allow that, I don't really see what the point of steno is.
In a country like Burma, they tend to just shut down the entire internet when the citizenry get "uppity".
Re: (Score:2)
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 bit
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.
Congratulations: Assuming you use the absurdly noticeable "empty packet" strategy, on a 20 megabit line with no other overhead,
Re: (Score:2)
I'm pretty sure he suggested sending the message inside a streaming video file, not sending a video through this method.
Through your suggested file size, he'd get about 10kb of data, which is plenty for text. If I were using this, I'd make a TerrorTube and use each clip to transmit something the size of a SMS.
Re: (Score:2)
Re: (Score:2)
Welcome to the world of stereotyping ... (Score:2)
What's worth the word Kleenex, Xerox or even Fax these days? It's not you and me defining words but everyone around us.
Those who don't understand everything will try to find anything "most like it" to define something they don't fully understand...
That definition is for them the most closest to steganography, which is a quite logical decision for those, knowing, packets normally don't involve secret injects of data...
It's sure not just "a hidden message" either to my definition ... Rstego maybe? ;)