Skip to main content

Counter-steganography research?

In the context of a national research fund, I recently stumbled across a project that deals with counter-steganography research. From an academic point of view, it is healthy to have security technology research and research trying to break these technologies. But when I had a closer look what kind of counter-steganography they were actually working on, I got worried.

The most common security breach in telecommunications is eavesdropping. Steganography and cryptography applied to telecommunication would both prevent that, the first by hiding the information, the second by talking in a language unknown to a third party listening. However, steganography is obviously more bandwidth demanding than cryptography, so why would anyone favour steganography over cryptography, when both achieve the same goals? Steganography has advantage that you can deny the existence of a hide message. Cryptographers call that plausible denial or deniable encryption.

StegIT (german) is a project that aims to prevent steganography in telecommunications (they aim for GSM/UMTS/VoIP). It works by mixing inauditable white noise into the conversation, so these "low bit" channels become unavailable for encoding hidden messages. StegIt does not aim to detect steganography, but its approach is to add this white noise to all conversations by installing equipment at your phone carrier. (To the german-speaking reader: Notice the wording they use in the project description. They speak of "steganographic attacks", and preventing these "attacks". Do they just desperately try to get funding or do they actually believe that?)

My initial reaction to StegIT was: "Why should I bother to use the low bandwidth channels at all? I would just drop those inaudible parts from my data channel and use regular encryption". I would loose the plausible denial property though, but is there is scenario where I would need that property? Yes, when encryption itself is outlawed (or made useless by laws for on-demand decryption).

This would only serve the purpose that eavesdropping is always available to law enforcement. But the idea to outlaw encryption sounded to remote to me... until I started googling that topic. Legislation concerning encryption is far from uncommon, see Crypto Law Survey by Bert-Japp Koops, who also provides us with some nice graphics.

Do I want my national security research fund to support a project that only make scene in a scenario where the right to encrypt -- your own personal guarantee for privacy -- is restricted? Definitely not.


Ron said…

I stumbled onto your blog and enjoyed reading your post. But this statement is incorrect: "However, steganography is obviously more bandwidth demanding than cryptography".

Changing the LSB in a bmp file does not use any more bandwidth. Same for changing the DCT coefficients in a jpg file. Was there a specific stego method you were thinking of?


By definition steganography hides information (hidden message) within other information (container).

Assuming the most trivial model, that a fixed portion of the container is dedicated to the hidden message -- lsbs of bmp files -- we see that the rest of the container does not contribute the hidden message and therefore is of no value to the user (of course that rests on the assumption that reason for communication is solely the hidden message)

If he had used cryptography, you don't have the overhead of the container. Hence it's more efficient. That was my point.

Popular posts from this blog

Liskell standalone

Some time has passed since I last blogged about Liskell. It is not dead nor have I changed my mind that Haskell needs a proper meta-programming facility not to mention a better syntax.Liskell was a branch of GHC once. Now it sits on top of the GHC API, or I should rather say sneaks behind its back as it creates its own API as the original one is not suitable for the stunts I'm interested in. If Liskell sticks with GHC as its soil, I will definitely send patches upstream to refine the GHC API in the areas where it needs more flexibility for Liskell. However for the moment, my main target was to get something out that compiles with a stable version of GHC.You can grab it with the usual: darcs get This version has been tested with ghc 6.10.1 and should install like: ./Setup.lhs configure ./Setup.lhs build ./Setup.lhs install cd LskPrelude make install-inplace Optionally you can run make tests in the testsuite subdirectory. Thanks to community.haskell…

XMonad GridSelect

Personally, I not just need a window manager, I need a focus manager. I tend to think of windows as TODO items, and as there are many TODOs in life there are many windows on my workspaces. Usually a fraction of that can't be closed or worked on immediately, so they linger around on my desktop, cluttering my workspace.I used to use the Tabbed layout. But Tabbed isn't the answer when you are a guy who reports bugs such as "XMonad 0.6 with Tabbed dies when firefox-session-restore slams 40 windows at once on the desktop". In other words, I use a lot of windows. The workspaces concept isn't particularly useful to me either. My mind just doesn't work with mental boxes. So the result is, that I have too few workspaces with too much windows on them, so that Tabbed has trouble displaying useful window titles, and navigating through them is slow and cumbersome (mostly because tab switching generates a lot of useless X Expose events).GridSelect is my answer to that. It…

Removing CHS based access from windows boot loaders

Recently, I had troubles to migrate my Windows installation from VMWare to VirtualBox. When booting the vmware created partition in virtualbox, I got "NTLDR not found". So I sharpened the knives and got down to business with vmware's gdb interface and virtualbox's internal debugger. Tracing the execution showed that the BIOSes of the two products reported different geometries on the INT 13h interface. The generic method contained in the boot loader to read a sector from disk is "clever" as it checks whether the sector is below the maximum sector index that is reachable with the CHS geometry reported by the BIOS. If not, it uses the LBA interface of the BIOS. If yes, the cleverness of the boot loader suddenly vanishes. Instead of using the BIOS reported geometry to break the absolute sector down into its CHS components, the boot loader uses a geometry stored in the so called BIOS parameter block. That's a section of the first sector embedded into the boo…