[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Having Meetings is the Most Important Issue
(I sent this off several hours ago and it still hasn't appeared at my
site, so I'm sending it again.)
From owner-cypherpunks Thu Mar 3 17:18:29 1994
Return-Path: <owner-cypherpunks>
Received: by toad.com id AA22067; Thu, 3 Mar 94 17:18:29 PST
Received: from jarthur.cs.hmc.edu by toad.com id AA22060; Thu, 3 Mar 94 17:18:25 PST
Message-Id: <[email protected]>
Subject: Re: Standard for Stenography?
To: cypherpunks list <[email protected]>
Date: Thu, 3 Mar 94 17:18:22 PST
From: Eli Brandt <[email protected]>
In-Reply-To: <[email protected]>; from "Jef Poskanzer" at Mar 3, 94 9:10 am
X-Arcane-Subliminal-Header: fooquayleglorkpsilocybinrkbapinkyogsothothquux
X-Mailer: ELM [version 2.3 PL11]
Sender: [email protected]
Precedence: bulk
Jef said:
> My solution is to store the file's bits in a specified
> pseudorandom permutation of the image's available bit positions.
> It's kind of like the frequency hopping of spread spectrum radio.
> This hides the length field very thoroughly. It also happens to
> hide anything else recognizable about the original file.
What you're doing can be written as
steg(permute(pkey, <length, encrypt(ekey, text)>))
Note that the permutation is really a second layer of encryption, a
bit transposition cipher. The obscurity-only approach of "#define
PERMUTE_KEY 0xdeadbeef" would be pretty weak. If an opponent is to be
unable to detect images with embedded steganography (stegnant
images?) by looking for the length field, the permutation needs to
be strong: large keyspace, strong PRNG, etc.
Granted, it doesn't need to be as strong as the message cipher,
because the plaintext is lousy (mostly encrypted), the payoff to the
opponent on breaking it is less, and the target pool is much
larger. But you do have the hassles of a second cipher -- at the
very least, you need to distribute keys. Probably *private* keys,
with their attendant distribution explosion.
I think the Right Thing to Do is to require that the length
indication or eof marker be inside the strong encryption (Stealth
PGP or what have you). Now, we may not want to do that. First, we
may have good reasons to preserve modularity by doing the length in
the stegger. If the encryption is stealthy, we can get away with
*only re-encrypting the length information*. Big win speedwise.
If the encryption is not stealthy, it seems to me that we need
a PGP headerstripper, not a permuter. The bulk of the file, after
all, *is* stealthy.
Tangentially, why choose bit permutation for your second-level
encryption? There are plenty of schemes that will be a lot faster
than doing all that bitmangling.
Eli [email protected]
From owner-cypherpunks Thu Mar 3 14:13:23 1994
Return-Path: <owner-cypherpunks>
Received: by toad.com id AA19804; Thu, 3 Mar 94 14:13:23 PST
Received: from mwunix.mitre.org by toad.com id AA19797; Thu, 3 Mar 94 14:13:14 PST
Received: from ciis.mitre.org (ciis.mitre.org [128.29.53.1]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id RAA12561; Thu, 3 Mar 1994 17:13:05 -0500
Received: from [128.29.103.48] (cfry-mac.mitre.org) by ciis.mitre.org (4.1/SMI-4.1)
id AA15217; Thu, 3 Mar 94 17:21:17 EST
Date: Thu, 3 Mar 94 17:21:12 EST
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [email protected] (Frederic Halper)
From: [email protected] (Curtis D. Frye)
Subject: Re: spooks
Cc: [email protected]
Sender: [email protected]
Precedence: bulk
>If there are any spooks on this list aren't they required by law to say that
>they are if somoeon asked if anyone on on th list was employed by CIA, DOD, FBI
>or NSA?
Hardly. The intel folks don't have to say diddley and might be prohibited
by law from saying anything, the FBI probably doesn't need to since there's
no criminal investigation under way (or is there?), and why in hell would
DOD employees need to reveal their presence? We encourage open, anonymous