Re: STEG: a real-life use for steganography

[fnerd@smds.com (FutureNerd Steve Witham)]

Eric talks about a hypothetical system S which he discussed with
real acquaintance X of country C (with repressive government G), 
for stegging information I in through exogenously-produced CDs of 
indigenous music M.

One problem is that S is proposed for use by lots of people in C.
That means the whole system won't be a secret for long.  Soon
G will know not only which records and which equipment to ban, but
also the passphrases for the records--so why encrypt or even
camoflage it?

Maybe making copies of existing popular records would help.
Classics that lots of people already have.  Are there already 
records produced for C but manufactured outside of C?  Do they 
import music popular outside C?

>  -- A facility to gather the data being put on the disks.  This by
> itself is no trivial task, since it involves the collection of many
> disparate sources.

Maybe the newsgroup you mention is just the thing for the second-to-
last step in the chain.  It can combine efforts of people who don't 
have to know each other.

>  -- An encryption system for the arranged data.  Such a system can't
> treat the data as one long stream, because of the segmented nature of
> the data.  

There's also the problem of recovering from errors on the CD.

> The ability to mount the CD as a file system would be good
> leverage for other programmers.

>  -- A decryption system to get the data off the CD.

Can most CR ROM drives read the raw music format?  Many?
If not, can the bit stream to the ADC in a CD player be intercepted?
Maybe the best hardware from a physical camoflage standpoint would be 
those little CDROM drives that double as "walkmen".

> A system to make rememberable sentences out of an
> arbitrary 128 bits (and the inverse) would be useful to facilitate
> word of mouth.

Isn't it good enough to always start with sentences invented by 
people and encode into bits?

> encoding and error correction systems used in CD's.  I do know that
> they are not simple, being much more than bit-correcting linear codes.

I think when they're not giving you exactly what you put in, they're
doing desparate things like repeating the last few milliseconds.  So
about all you can do is put CRCs and IDs on blocks (maybe small 
blocks?) and be able to deal with lost and misplaced blocks.
It might be useful to have signatures on block boundaries so you could
recognize them out of continuous streams.  Maybe you would just take
two blocks worth of data and slide your buffer along one byte at a
time till you got a good CRC...but by then you would have received
a lot more data.  Better have a long buffer.

>  -- A standard for the encoding of file system data onto these low
> bits.  This should be a separate document, even though the design of
> this will be influenced by the bit encoding standard.  Some adaptation
> of existing file system standards may be appropriate.

Here, too, you need to deal with lost blocks.  Having one copy of the
root of the index might not be great.  Also, assuming you're using
modified CD players instead of CDROM drives, you might want to take
advantage of the music track structure.

-fnerd
quote me

- -
skip sweet sweetbacks badass skipjack song, jack.  3x, fast.
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
sRjLQs4iVVM=
=9wqs
-----END PGP SIGNATURE-----