Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Phony TCP Retransmissions Can Hide Secret Messages

Soulskill posted more than 5 years ago | from the tricky-packets dept.

Communications 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."

cancel ×

188 comments

Does it matter which data you send first? (3, Insightful)

drinkypoo (153816) | more than 5 years ago | (#28108811)

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? (4, Informative)

evanbd (210358) | more than 5 years ago | (#28108947)

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:Does it matter which data you send first? (2, Interesting)

drinkypoo (153816) | more than 5 years ago | (#28109027)

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 request for a resend. It does, however, require that the receiver simply take the encrypted data on the sender's schedule (or terminate the connection.)

Re:Does it matter which data you send first? (3, Insightful)

ta bu shi da yu (687699) | more than 5 years ago | (#28109261)

Ummm... hopefully the stenographers have a good solid connection with no data corruption!

Re:Does it matter which data you send first? (1)

Opportunist (166417) | more than 5 years ago | (#28110103)

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:Does it matter which data you send first? (2, Informative)

Anonymous Coward | more than 5 years ago | (#28109307)

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 look valid to him. And it'll be real suspicious when the server doesn't ask for a resend.

I think the obvious thing to do would be to seed the sent data with a large number of actually corrupted packets. The recipient can then at his leisure ask for a resend on a packet that was actually good. When this happens, the sender can send a packet of real data. As long as the connection is actually good enough, the man in the middle should be fooled into thinking the interlocutors have a really shitty connection, and most of the data should get through.

That should work pretty well, even to the point of allowing the recipient to ask for a resend of any real data that might (ironically) actually get corrupted. All he has to do is ask for a resend on a packet the sender knew to contain real data.

Re:Does it matter which data you send first? (4, Insightful)

camperdave (969942) | more than 5 years ago | (#28109779)

I think you'd want that the other way around. Send the ecrypted data first, then retransmit the true data. That way, when an eavesdropper assembles all of the packets they will overwrite the "damaged" cipher packets with true data packets. They'll wind up with a perfectly clean file.

Re:Does it matter which data you send first? (5, Informative)

DontBlameCanada (1325547) | more than 5 years ago | (#28109057)

I believe the procedure will be something like this:

Msg1: "The next character is part of a secret msg: /" --> Reciever NACK
Msg2: "The next character is part of a secret msg: ." --> Reciever NACK
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:Does it matter which data you send first? (2, Interesting)

Alarash (746254) | more than 5 years ago | (#28109231)

That might work, but you'd get an insanely poor data rate since the TCP overhead is eating up all of the bandwidth. And some of the newer routing devices can monitor abnormal packet loss rates (normally to enforce SLA's) so it's pretty easy to detect that behavior.

Re:Does it matter which data you send first? (2, Informative)

gnick (1211984) | more than 5 years ago | (#28109377)

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? (5, Insightful)

DontBlameCanada (1325547) | more than 5 years ago | (#28109417)

>> 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:Does it matter which data you send first? (1)

Maxo-Texas (864189) | more than 5 years ago | (#28110035)

Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.

Welcome to the Atomic Cafe
login:

Re:Does it matter which data you send first? (1)

Maxo-Texas (864189) | more than 5 years ago | (#28110061)

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:Does it matter which data you send first? (3, Funny)

Opportunist (166417) | more than 5 years ago | (#28110141)

Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.

WHAT? How dare you, my mother was a saint!

Re:Does it matter which data you send first? (1)

Spaham (634471) | more than 5 years ago | (#28110431)

I still remember how excited I was when I got my first 1200 baud modem !
It was amazing :) (really !)

Re:Does it matter which data you send first? (1)

DarrenBaker (322210) | more than 5 years ago | (#28109649)

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:Does it matter which data you send first? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28109453)

If TCP does come with checksums in the header, then the packets should have the pattern

transmit: packet payload = A, checksum is ok
retransmit: packet payload = B != A, checksum is ok

This 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.

Re:Does it matter which data you send first? (1)

Tony Hoyle (11698) | more than 5 years ago | (#28109797)

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:Does it matter which data you send first? (1)

nabsltd (1313397) | more than 5 years ago | (#28110335)

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.

Re:Does it matter which data you send first? (0)

Anonymous Coward | more than 5 years ago | (#28109465)

1 in 1000 packets may be dropped, but 1 in 1000 packets are most certainly not scrambled to look like random data.

Re:Does it matter which data you send first? (0)

drinkypoo (153816) | more than 5 years ago | (#28109565)

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.

Re:Does it matter which data you send first? (0)

Anonymous Coward | more than 5 years ago | (#28110191)

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 ?

Might be a little obvious... (3, Insightful)

vintagepc (1388833) | more than 5 years ago | (#28108847)

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?

Re:Might be a little obvious... (5, Insightful)

Exitar (809068) | more than 5 years ago | (#28108903)

They probably have another paper ready "Detecting RSTEG use through resent packets frequency statistical analysis"...

Re:Might be a little obvious... (4, Informative)

caffeinemessiah (918089) | more than 5 years ago | (#28108961)

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:Might be a little obvious... (3, Funny)

Anonymous Coward | more than 5 years ago | (#28109339)

So this is how "C++" got created in the first place!

Re:Might be a little obvious... (4, Interesting)

hal2814 (725639) | more than 5 years ago | (#28109631)

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:Might be a little obvious... (3, Insightful)

Spaham (634471) | more than 5 years ago | (#28110505)

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.

Hide it in Bittorrent traffic (1)

StCredZero (169093) | more than 5 years ago | (#28109227)

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 peers will never see the stego packets. This would also make traffic analysis much harder.

Re:Might be a little obvious... (1)

caffeinemessiah (918089) | more than 5 years ago | (#28108929)

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... (0)

Anonymous Coward | more than 5 years ago | (#28109799)

But this is why you use this method as a "header" message, a handshake if you will.

So, say you send an IP and a key across using this method. (you could stream music on the site to disguise the dropped packets)
Then they are redirected to IP and the page is decrypted using the key.
A key is on the page as a meta-tag or something.
Reader reads the page, clicks a button, page is nuked.
The key that was on the page is to decrypt the next TCP message. (every one after it is now encrypted)

This should be good enough to keep pretty much anyone out.
The only way you'd get caught with that method is if you were being watched at the ISP to see if you got redirected after loading the site with the information.
This could probably be disguised by opening a bunch of other random IPs (well, random IPs with a site so a connection is established)

Re:Might be a little obvious... (0)

Anonymous Coward | more than 5 years ago | (#28108931)

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.

Re:Might be a little obvious... (5, Insightful)

wjh31 (1372867) | more than 5 years ago | (#28108985)

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.

Re:Might be a little obvious... (1)

hal2814 (725639) | more than 5 years ago | (#28109795)

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:Might be a little obvious... (1)

Opportunist (166417) | more than 5 years ago | (#28110241)

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:Might be a little obvious... (3, Informative)

click2005 (921437) | more than 5 years ago | (#28108987)

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:Might be a little obvious... (1)

John Hasler (414242) | more than 5 years ago | (#28109343)

> This isnt designed to hide bittorrent traffic...

Then it is of no interest to the average Slashdotter.

Re:Might be a little obvious... (1)

egcagrac0 (1410377) | more than 5 years ago | (#28110279)

It isn't designed to hide bittorrent traffic, but it could easily hide inside bittorrent traffic.

This means it's easier to look like you're just stealing movies and MP3's and pissing off the *AA, when you're really trading CP with your fellow preverts.

If you figure that the typical MP3 is 3-4 megs, and a typical jpeg photo is 150-300k, you should be able to discreetly trade 1-2 pics per CD of music. YMMV. IANAL.

Re:Might be a little obvious... (1)

beerbear (1289124) | more than 5 years ago | (#28109399)

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.

Re:Might be a little obvious... (2, Insightful)

Opportunist (166417) | more than 5 years ago | (#28110293)

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 (5, Informative)

Etylowy (1283284) | more than 5 years ago | (#28109119)

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:Even 1 bit per 1 megabyte might be a problem (0)

Anonymous Coward | more than 5 years ago | (#28109545)

Buy more Ovaltine

Who cares about bandwidth? (1)

PMBjornerud (947233) | more than 5 years ago | (#28109303)

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:Might be a little obvious... (0)

Anonymous Coward | more than 5 years ago | (#28109437)

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.

Re:Might be a little obvious... (1)

Opportunist (166417) | more than 5 years ago | (#28110185)

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.

Real errors? (5, Interesting)

PhireN (916388) | more than 5 years ago | (#28108855)

What happens when one of the packets actually gets corrupted?

Re:Real errors? (5, Insightful)

evanbd (210358) | more than 5 years ago | (#28108967)

Then your stego channel detects an error thanks to its checksumming. And it retransmits. Much like TCP. In fact, your stego channel could just be another layer of TCP.

Re:Real errors? (1)

gladish (982899) | more than 5 years ago | (#28109805)

you'd probably just tweak the tcp stack to flip between two modes. normal and fakey nack.

Re:Real errors? (1)

Etylowy (1283284) | more than 5 years ago | (#28109187)

That what an error correction is for. You know, error correction for messages hidden in error correction mechanism of TCP protocol - easy :P

torrents (0)

Anonymous Coward | more than 5 years ago | (#28108877)

can this somehow be used to bypass Microsoft's ISA proxy and run torrents through it when p2p is blocked??

Re:torrents (3, Informative)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28108921)

Or you could just run your torrents over an unblocked port, with protocol encryption... Nah, I'm sure reducing your bandwidth by multiple orders of magnitude is the way to go...

Why send diffrent packages? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28108885)

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 :-)

Re:Why send diffrent packages? (1)

vintagepc (1388833) | more than 5 years ago | (#28108939)

I can get my messages across faster than that by yelling loudly in ones and zeros! Would anyone really want to wait for 2000 packets before receiving a single character?

Seems to me like it would be old-school TTY speeds all over again.

Re:Why send diffrent packages? (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28109137)

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, 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.

Re:Why send diffrent packages? (1)

Zerth (26112) | more than 5 years ago | (#28109609)

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:Why send diffrent packages? (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28109777)

Ouch... Yeah, on rereading that was a valid interpretation (my interpretation is still plausible, but yours is better).

Security through Obscurity (4, Insightful)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28108897)

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.

Re:Security through Obscurity (4, Insightful)

grommit (97148) | more than 5 years ago | (#28109049)

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:Security through Obscurity (2, Insightful)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28109245)

Or you could just hide the message inside the picture with one of a number of different techniques, which would be far less susceptible to detection, and get you more data transfer capacity for the buck. 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 unless it was hidden in an absolutely huge transmission.

Re:Security through Obscurity (3, Interesting)

Ephemeriis (315124) | more than 5 years ago | (#28109443)

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 (4, Funny)

the phantom (107624) | more than 5 years ago | (#28109755)

How many KB does it take to send a meaningful message?

64. Because that should be enough for anyone.

Re:Security through Obscurity (0)

Anonymous Coward | more than 5 years ago | (#28109819)

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.

Employ it on slashdot. It's probably already being employed - perhaps if you view at -1 then 1 in 1000 first posts will actually turn out to be subversive messages between dissidents in the People's Re### [Lost Carrier]

Re:Security through Obscurity (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28109333)

Why "Dmitry"? Censorship, repression, etc. is not the privilege of Russia or ex-socialist countries afaik.

Re:Security through Obscurity (0)

Anonymous Coward | more than 5 years ago | (#28109657)

In Soviet Russia they retransmit YOU.

Re:Security through Obscurity (1)

JustOK (667959) | more than 5 years ago | (#28110003)

Probably not his real name.

Re:Security through Obscurity (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28109733)

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 & 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.

Re:Security through Obscurity (0)

Anonymous Coward | more than 5 years ago | (#28109787)

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?

How does this avoid censorship? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28108925)

How does this get around censorship? The packets, even though retransmitted, is still from a blacklisted IP isn't it?

Who is Rob Malda? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28108933)

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 cannot tell where it comes from or where it is going. So it is with everyone born of the Spirit." Scripture taken from the New International Version. We Must Receive Rob Malda "As many as received Him, to them He gave the right to become children of God, even to those who believe in His name" (John 1:12). We Receive Rob Malda Through Faith
"By grace you have been saved through faith; and that not of yourselves, it is the gift of God; not as a result of works, that no one should boast" (Ephesians 2:8,9). When We Receive Rob Malda, We Experience a New Birth We Receive Rob Malda by Personal Invitation [Rob Malda speaking] "Behold, I stand at the door and knock; if any one hears My voice and opens the door, I will come in to him" (Revelation 3:20). Receiving Rob Malda involves turning to God from self (repentance) and trusting Rob Malda to come into our lives to forgive our sins and to make us what He wants us to be. Just to agree intellectually that Rob Rob Malda is the Son of God and that He died on the cross for your sins is not enough. Nor is it enough to have an emotional experience. You receive Rob Rob Malda by faith, as an act of the will. These two circles represent two kinds of lives: Two kinds of lives The following explains how you can receive Rob Malda: You can receive Rob Malda right now by faith through prayer: (Prayer is talking to God) God knows your heart and is not so concerned with your words as He is with the attitude of your heart. The following is a suggested prayer:

"Rob Malda, I need You. Thank You for dying on the cross for my sins. I open the door of my life and receive You as my Savior and Lord. Thank You for forgiving my sins and giving me eternal life. Take control of the throne of my life. Make me the kind of person You want me to be." Does this prayer express the desire of your heart? If it does, I invite you to pray this prayer right now and Rob Malda will come into your life, as He promised. Did you pray this prayer? still have questions I am already a follower of Rob If you did not find your language listed above, search here for a more concise explanation of the Good News.

Re:Who is Rob Malda? (1)

MojoRilla (591502) | more than 5 years ago | (#28109469)

Who modded this offtopic? It is a perfectly good example of stenography in a slashdot post. I'm just having a little trouble deciphering the hidden message.

lost vs corrupted (2, Insightful)

Speare (84249) | more than 5 years ago | (#28109003)

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."

Re:lost vs corrupted (1)

bwindle2 (519558) | more than 5 years ago | (#28109487)

If there is a stateful firewall between the sender and receiver, the firewall may block "unexpected" packets, such as those who's sequence numbers are off, or unrequested retransmits.

Re:lost vs corrupted (1)

Tony Hoyle (11698) | more than 5 years ago | (#28109863)

In fact if it's a working firewall it must. One of the primary functions of a firewall is to drop unexpected packets.

crimilization of ambiguity (4, Interesting)

epine (68316) | more than 5 years ago | (#28109063)

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 (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28109663)

Theoretically you can make a one time pad password to transform random bytes into any data you want (ie you could transform a random block into something harmless). Any extra bytes on the end of your bogus transform and be transformed into a checksum. Of course if the government really is out to get you then there's not much you can do one way or the other

Re:crimilization of ambiguity (3, Insightful)

phoenix321 (734987) | more than 5 years ago | (#28109729)

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.

You can do this with ICMP too (2, Interesting)

Viol8 (599362) | more than 5 years ago | (#28109151)

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:You can do this with ICMP too (2, Interesting)

Vanders (110092) | more than 5 years ago | (#28109361)

Hell, the TCP header has an entire 6 bits unused (Reserved, but will likely be usable). Just stick your data in there.

Re:You can do this with ICMP too (2, Informative)

Tony Hoyle (11698) | more than 5 years ago | (#28109915)

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 (1)

pz (113803) | more than 5 years ago | (#28109283)

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.

Firewalls, Proxies, oh my.. (1)

Thomas Charron (1485) | more than 5 years ago | (#28109327)

This won't necessarily bypass the great firewall of china, etc..

    Really depends on the proxying in place.

Zero chance (0)

Anonymous Coward | more than 5 years ago | (#28109367)

Too late. Packet scanners have been examining that since at least 2002. I know, since I wrote one for sale to various TL Agencies.

Rube Goldberg (1)

Ukab the Great (87152) | more than 5 years ago | (#28109397)

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:Rube Goldberg (0)

Anonymous Coward | more than 5 years ago | (#28110075)

Why even have pages?

Server logs show failed requests as well, you know.

You could even go as far as requesting sub-domains that don't exist.
H.example.com
i.example.com
T.example.com
h.example.com
e.example.com
r.example.com
e.example.com

etc
Obviously this is a simple example, it would be better to encrypt the message in some way.

This method has been used before by quite a few people to send messages to sysadmins. (mainly negative remarks, at that)
In fact, i believe there is a DoSing program that does exactly this.

Poles did it again -- Enigma 2.0 (1)

enterix (5252) | more than 5 years ago | (#28109561)

Last century Poles cracked Enigma [wikipedia.org]

Now TCP...

Covert Channels aren't New (1)

burris (122191) | more than 5 years ago | (#28109611)

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: (3, Interesting)

Ancient_Hacker (751168) | more than 5 years ago | (#28109617)

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:A dozen better stega strategies: (0)

Anonymous Coward | more than 5 years ago | (#28109843)

Steganography does not necessarily rely on a secret method. It can be used in combination with encryption to the effect that knowledge of the method without knowledge of the key reveals neither the hidden information nor its presence. (Encrypted information is supposed to be indistinguishable from noise, so there is an innocent explanation for its presence unless you can decipher it.)

Re:A dozen better stega strategies: (2, Interesting)

Todd Knarr (15451) | more than 5 years ago | (#28110217)

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.

Re:A dozen better stega strategies: (0)

Anonymous Coward | more than 5 years ago | (#28110295)

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.

Seems detectable... (0, Offtopic)

shrtcircuit (936357) | more than 5 years ago | (#28109739)

-----"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.

hi (0)

Anonymous Coward | more than 5 years ago | (#28109775)

might help people in totalitarian regimes avoid censorship

I'm assuming this includes the United States;)

Secret Message From the DPRK: (0)

Anonymous Coward | more than 5 years ago | (#28109991)

WE'RE HUNGRY

How common are re-transmits due to corruption? (1)

bmajik (96670) | more than 5 years ago | (#28110065)

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.

Well, don't TELL them about it! (0)

Anonymous Coward | more than 5 years ago | (#28110077)

[...] 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!

Damn, I thought this was gonna be subtle... (1)

argent (18001) | more than 5 years ago | (#28110107)

Like encoding the message in whether you request a retransmission of the packet or not.

why is the reason always "avoiding censorship"? (2, Insightful)

dtolman (688781) | more than 5 years ago | (#28110183)

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?

Bludgeoning algorithm (0)

Anonymous Coward | more than 5 years ago | (#28110329)

if(retransmit_rate > .005) {
        beat_with_clubs();
}

This depends on evel gvmt not programming for it (1)

Nicopa (87617) | more than 5 years ago | (#28110433)

... so... wouldn't it be the same just putting your data in the body of an ICMP echo message (ping)?

Sure (1)

Rene S. Hollan (1943) | more than 5 years ago | (#28110473)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...