From: aba@dcs.exeter.ac.uk
Date: Fri, 16 Feb 1996 21:39:07 +0800
To: warlord@MIT.EDU
Subject: Re: Stealth PGP work
In-Reply-To: <199602141830.NAA02458@toxicwaste.media.mit.edu>
Message-ID: <11009.9602141935@dart.dcs.exeter.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain



Derek Atkins <warlord@mit.edu> writes on cpunks:

> I'm not familiar with the exact details of what stealth does, which is
> why I asked for more details.  

OK stealth is quite simplistic in the way it operates... neglecting
the pgp conventional encrypt support, here's what it does...

It takes a PGP message which looks like this (must be unarmored),

+---------+--------------------------------+----------+----------
| rsa CTB | RSA encrypted IDEA session key | IDEA CTB | IDEA encrypted data ..
+---------+--------------------------------+----------+----------

and outputs this:

+--------------------------------+---------------------+
| RSA encrypted IDEA session key | IDEA encrypted data |
+--------------------------------+---------------------+

(the point of stealth 2.01 is that the RSA encrypted session keys for
a given user will be less than that users RSA modulus by definition,
and hence not evenly distributed, and that this would be noticeable
statistically after a few messages)

So in stealth 2.01 the RSA encrypted IDEA session key is actually
transformed by a function on stealthing, and the reverse of that
transform is applied on unstealthing.  Before the transform:

0 < r < n

where r is the encrypted session key, and n is the users public key.

The transform ensures that, f(r) is uniformly distributed in:

0 < f(r) < 2^x 

(x depends on a security parameter, higher security implies greater
expansion, 2^x is of course greater than n, otherwise information
would be lost)

stealth 2.x requires n to perform the transform f, and the inverse f'.
when stealthing the n chosen is that specified in the RSA header.

on unstealth f' is used to recover, and n is again required, the n
chosen must be either specified as a user id to look up, or all
user-ids must be inspected.

The unstealth operation re-constructs the headers.

(One "feature" is that you can pad random junk after the stealthed
message and the unstealth, pgp decrypt operation still seems to work
because of the nested length bytes contained within IDEA encrypted and
within compression packets.  This is useful as it allows you to pad
your data to a fixed size in a similar way to mixmaster packets).

> The problem is that PGP API, when decrypting a message, keys off the
> PGP packet types in order to operate.

Right, understood.  I would have thought it nice to add support for
usage of the modules in the pipeline that you describe in an
independent manner also, as building blocks?  Perhaps this is already
catered for.  The problem with stealth from this point of view though
is that there is no packet.  Perhaps you could prime the pipeline by
prepending a dummy `stealthed' CTB, and a method to cope with this CTB?

> If stealth can work outside of PGP 2.6.2, then it should be possible
> to add it on to PGP 3, theoretically.

Stealth can work outside of PGP, but it duplicates work - it looks up
keys in the database to obtain the keyid to insert on unstealth (and
in 2.01 it also needs to know the rsa modulus on stealth and
unstealth).  The other functionality 2.01 duplicates is that it needs
cryptographically strong random numbers, I have not resolved this
satisfactorily, which is why stealth2.x has not be developed further
than beta stage.

The limitation of stealth is that it only supports a single recipient,
in that it expects the data following the key to be the IDEA encrypted
data.

Possibly pgp3 will make this easier, will give access to the random
number generator as an API call?

Will it provide API calls to allow key lookup?

(Maybe I should hold off more questions until you have the API ready
for release).

> [...]  To add stealth, you just add a stealth module in there.
> However I can tell you now that we are not working on such a module
> for the PGP 3.0 release.
>
> I'll hopefully have the API Spec and Programmer's Guide in a state
> where I can let others see it in the near future.  But since I'm going
> to be off the net for about a week or two at the end of the month, it
> might have to wait until March unless a miracle happens in the next
> week.

Perhaps you can accept a donated stealth module at a later stage, if I
understand the API spec and prog guide well enough I might try to
produce one of these .  I'm sure Colin & yourself have lots to do as
is.

> I hope this helps.

Clarifies quite a few things, yes thanks,

Adam