[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: Eason/Kawaguchi stego
From:       Anonymous <nobody () replay ! com>
Date:       1999-06-30 17:46:02
[Download RAW message or body]

Bill Frantz writes:

> It seems to me you could use an existing public key infrastructure, e.g.
> PGP, but build a different message format with the stego requirements in
> mind.  Off the top of my head (using PGP 2.6):
>
> (size, data)
> (256, key) - RSA encrypted key padded with pseudo-random padding to
>              256 bytes. (The size of the RSA key will determine the
>              size of the encrypted session key, and the receiver knows
>              the size of the RSA key.)
> (8, IV)    - The (random) initialization vector
> (n, data)  - The data encrypted with 3DES in CBC mode + whatever padding
>              scheme suits your fancy.  I like having the first 8 byes
>              of encrypted data being the length of the data.
> (m, pad)   - Pseudo-random padding to fill out the stego block.

Right, this was discussed many years ago on the cypherpunks list.
Your idea works, but the RSA padding needs to be done a bit carefully;
padding to 256 bytes is unnecessary for 1024 bit moduli and inadequate
for 2048 bit moduli.

The issue with the RSA encrypted session key is that it is not a random
series of bytes, because it is constrained to be less than the RSA modulus.
If people would create keys whose RSA moduli start with about 8 bytes of
0xff then this would not be detectable in practice, but since most people
do not do this you need to do some padding.

A simple approach is to pad the encrypted value up to about 8 bytes longer
than the modulus, such that the resulting padded value, when taken mod
the modulus, equals the original encrypted value.  This can be done by
adding a multiple of the modulus, where the multiplier is randomly chosen
from 0 to that which would make the result the desired size.  The result
will be effectively indistinguishable from a random series of bytes.

Note that, with possession of the target public key, you can almost
transform a PGP encrypted message to this stego format and back.  The
only problem is dealing with the random padding when you convert back,
but PGP does have an encrypted packet length and it may ignore random
encrypted noise at the end.

[prev in list] [next in list] [prev in thread] [next in thread]