At 04:22 AM 12/04/1997 -0600, William H. Geiger III wrote:
I believe that there is a program PGP Stealth that works well for striping
this information from PGP messages before Stego is applied.
We had a rather lengthy discussion on Stego techniques on #pgp the other
day. I have primarily playing with the bit hiding and haven't looked too
much at the PGP header striping. I imagine that if a PGP implementation
could not handle a "striped" PGP message that the Stego preprocessor could
"fix" the encrypted message before passing it to PGP.
This isn't a spelling flame, but you're ambiguous here - do you mean
- "Stripping" - taking out unnecessary stuff, or
- "Striping" - spreading information out in thin stripes, similarly
to striped file systems spread across disk drives
?
But yes, using an all-zero KeyID as a speculative mode would
fit in very well with a stealth preprocessor, which can
use whatever values it wants in the field when stealthed,
and then replace with 0s when destealthing if it doesn't
have a better alternative.
On the other hand, if OPGP does support the 0s mode,
it'll have to successively try each secret key it has
until it either finds one that works or finds that
none of them work; an alternative is to have an external
preprocessor program that drives it, by trying each KeyID in succession.
This requires that the driver know what KeyIDs are available
(either reading directly from the keyring or
just from a list), and that the OPGP implementation
have some easily-parsed response that lets the driver
decide whether or not the decryption worked.
Another option is to only check the "default" key,
though default key really an artifact of the user interface
rather than something OPGP needs to know about.
Internal support is more efficient, but non-critical,
so I'd recommend against making it a MUST, but it'd be
nice to have it as a SHOULD.
Thanks!
Bill
Bill Stewart, stewarts(_at_)ix(_dot_)netcom(_dot_)com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639