Unknown address

Hi!  Could you tell me why I receive this message?!?

I *never* sent anything to your place...

What is it that is wrong? The cypherpunks remailer?  Your site? (how?)



========== original e-mail from you ================
>From warehouse.mn.org!postmaster@kksys.com Mon Feb 12 04:06:24 1996
Return-Path: <warehouse.mn.org!postmaster@kksys.com>
From: postmaster@warehouse.mn.org (Postmaster)
Subject: Unknown address
Date: Sun, 11 Feb 1996 22:19:49 GMT
Organization: The Warehouse BBS
To: jf_avon@citenet.net )

>The user this message was addressed to does not exist at this site.  Please
>verify the name and domain in the original message that follows.
>Message was addressed to: SAMUEL.KAPLIN@warehouse.mn.org
>
>                     ----- Original Message follows -----
>
>From: jf_avon@citenet.net (Jean-Francois Avon (JFA Technologies, QC, Canada))
>To: cypherpunks@toad.com
>Date: Sun, 11 Feb 1996 23:41:06 -0500
>Subject: Re: "Rights"
>
>Ed.Carp@linux.org, ecarp@netcom.com wrote:

<various blah blah from me snipped>

========= end original message from you ================
**** NEW PGP 2.6.2 KEY *********

2048 bits Key ID:24201BA1 1996/02/13 Jean-Francois Avon <jf_avon@citenet.net>
Key fingerprint =  23 B6 24 31 86 67 FB 35  C7 A7 AF 12 A1 61 E9 3D 


**** OLD KEY: DO NOT USE ANYMORE UNLESS FOR VERIFYING SIGNATURES ****

1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon@citenet.net>
Key fingerprint =  84 96 76 AE EB 7C AB 15  88 47 87 B0 18 31 74 9F

> It seems that there a market demand for a stealth-capable product.
> Many peoples here seems to discuss it.  And for the time being, AFAIK,
> this type of products are used by a specific class of peoples, most of
> which knows what 'stealth' means.
> 
> So why is it that they design a program that would not permit the use
> of a feature considered desirable by it's customer base?

The big question I have for you is, what do you mean by "stealth" PGP?
Do you want a PGP message which doesn't say to whom it is encrypted?
Or do you want a PGP message which does not even acknowledge that it
is a PGP message?  If what you want is the former, then that can fit
under the PGP API fairly well.  If you want the latter, it will not.

The reason is that PGP, by definition, is a self-describing packet
format.  Without that description there is no general way for the PGP
library to discover what kind of message it is parsing order to
perform the proper operation to open the message.  OTOH, if just the
keyID is missing, the library will happily try all the keys on your
secret keyring until one succeeds or they all fail (I'm not sure if
this is implemented, but it fits quite nicely under the API).

The other question I have is: who do you think the "customers" of PGP
are?  If you think the majority of PGP's customers are the
crypto-privacy activitst types, you are highly mistaken.  PGP has hit
the main stream, and is being used by many non-crypto-aware people.
Probably more of them than there are of us.

If you want to discuss this more, let's take it to private email,
please.

-derek

Derek Atkins <warlord@mit.edu> writes on cpunks:
> > It seems that there a market demand for a stealth-capable product.
> > Many peoples here seems to discuss it.  And for the time being, AFAIK,
> > this type of products are used by a specific class of peoples, most of
> > which knows what 'stealth' means.
> > 
> > So why is it that they design a program that would not permit the use
> > of a feature considered desirable by it's customer base?
> 
> The big question I have for you is, what do you mean by "stealth" PGP?

I presume he means stealth, and the functionality that it provides, as
a filter for pgp versions 2.x.  The question in the minds of users of
this utility (for steganography applications) I think will be will
stealth still work with pgp3.0, and would it useful to include as
built-in functionality for pgp3.0.  I raised this question myself to
the pgp3 development team some time ago, and the reply I got was
essentially that it would still be possible to have as an add-on, so
there was no need to clutter the pgp3 functionality.

Henry Hastur's stealth 1.3 is included with pgp2.6.3i in the
contributions directory...

> Do you want a PGP message which doesn't say to whom it is encrypted?
> Or do you want a PGP message which does not even acknowledge that it
> is a PGP message?  If what you want is the former, then that can fit
> under the PGP API fairly well.  If you want the latter, it will not.

For steganography applications both are required (actually a
transformation formulated by Hal Finney, or an equivalent by Bodo
Moeller is necessary to add more than casual strength to the degree of
plausible deniability due to the fact that the rsa encrypted header
will always be less than the rsa modulus).

I haven't looked at the PGP3 API, but why will a stealth option not
fit?  If stealth can perform the operation as a separate program, why
is it infeasible or difficult for pgp3 to support a stealth option,
and another to support unstealth to a particular recipient.  (With
stealth on decrypt the user provides the user id they think the
message will be addressed to).

On encrypt, the stealth operation should be real easy to implement
inside PGP, it is just another post-filter operation like ascii armor,
stealth instead.

On decrypt, it is more tricky because firstly you loose information
about what kind of data it was, and secondly because you loose the
recipient user id if it was encrypted data.

However, if you provide an API call to unarmor with out decrypting,
and a call to decrypt with out uncompressing, etc then a call to test
for a particular user id on the assumption that it is addressed to
that user id and is an encrypted message would fit in a similar way?

Also note that the rest of the information, once this operation has
suceeded is retained inside the encryption envelope - the length tag,
signature, whether it is further compressed, and so forth.

The stealth operation as implemented in Henry's 1.3 is not all that
secure, and I had an attempt at implementing Hal Finney's algorithm to
produce a stealth 2.0.  My attempts are at:

	http://www.dcs.ex.ac.uk/~aba/stealth/

This is beta code, and I presume the reason that Stale included
stealth 1.3 rather than stealth2.01b with pgp263i was either that 2.01
is beta, or because he did not know it existed.

The reason that the code is beta, is that I had a problem in
implementing stealth as a standalone.  The problem is that Hal's
algorithm has a requirement for cryptographic quality random numbers.
It seems silly to duplicate all this code inside stealth when pgp
provides it internally.  And the (+makerandom=n file) option is not
convenient, because stealth is invoked as a filter with pipes, and
invoking pgp twice doesn't seem like a good idea.  It might even be
dangerous (interferring with the normal sequence of randseed
stirring)?  Besides I had gone to some pains in stealth2.0 to ensure
that nothing hit the disk at all if sufficient memory was available to
do without.

> The reason is that PGP, by definition, is a self-describing packet
> format.  Without that description there is no general way for the PGP
> library to discover what kind of message it is parsing order to
> perform the proper operation to open the message.

stealth allows you to specify encrypt or decrypt, if decrypt the user
id to insert.  It also supports conventional encryption.

> OTOH, if just the keyID is missing, the library will happily try all
> the keys on your secret keyring until one succeeds or they all fail
> (I'm not sure if this is implemented, but it fits quite nicely under
> the API).

That would be a useful functionality from stealths point of view.

> The other question I have is: who do you think the "customers" of PGP
> are?  

He expressed his request in terms of customer demand...

> If you think the majority of PGP's customers are the crypto-privacy
> activitst types, you are highly mistaken.  PGP has hit the main
> stream, and is being used by many non-crypto-aware people.  Probably
> more of them than there are of us.

PGP was started on idealogical grounds, my argument for including
stealth, or as much stealth compatible options as fit within the API
model, is that there are countries where crypto is illegal.  It is not
100% certain that the US won't one day join them (what do you rate the
odds of a mandatory GAK appearing in the US?).  I'd view it as part of
PGP's guerrilla privacy features, and a precaution against such worst
case scenarios.  Besides stego applications have their own set of
uses, albeit they are not in mainstream use in the same way that pgp
is.

> If you want to discuss this more, let's take it to private email,
> please.

I'd prefer to see the discussion on the list, or at least cc me in
such discussion.  Any reason for private email?  The topic is
cryptography related,

Adam

> I presume he means stealth, and the functionality that it provides, as

I'm not familiar with the exact details of what stealth does, which is
why I asked for more details.  The problem is that PGP API, when
decrypting a message, keys off the PGP packet types in order to
operate.  If stealth can work outside of PGP 2.6.2, then it should be
possible to add it on to PGP 3, theoretically.

>   I raised this question myself to
> the pgp3 development team some time ago, and the reply I got was
> essentially that it would still be possible to have as an add-on, so
> there was no need to clutter the pgp3 functionality.

And in some ways this is true.  The PGP API does allow for add-ons.
I'll explain what I mean later in this message.  Then again, I don't
know to whom you spoke.  The "PGP 3 development team" has changed a
lot over the last couple years.  At this point, for all practical
purposes, there only two people on the team.

> However, if you provide an API call to unarmor with out decrypting,
> and a call to decrypt with out uncompressing, etc then a call to test
> for a particular user id on the assumption that it is addressed to
> that user id and is an encrypted message would fit in a similar way?

It is not implemented directly in this manner, but it is possible to
get this functionality.  The application will get a callback at which
point it can direct the PGP library.  For example, if you want to
dearmor but not decrypt, when you get to the encryption part you tell
it not to continue and to just output the encrypted block.

Basically, the PGP Message Processing API is based on a pipeline
model.  You have a bunch of pipeline modules that are connected, and
each module performs some transformation on the data.  For example,
you have a text module that goes into a literal module which goes into
a signature module which goes into an encryption module which then
goes into an armor module.  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.

I hope this helps.

-derek

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

Jean-Francois Avon (JFA Technologies, QC, Canada) writes:
> Q3: how to make that connexion [from mid ocean] *secure*?

Ah, that part is easy. End to end encryption. IPsec or things like
it. I hope I don't sound like a preacher, but IPsec is a good thing(TM).

Perry

Jean-Francois Avon writes:
> Hi!  Could you tell me why I receive this message?!?
[...]
> >The user this message was addressed to does not exist at this site.  Please
> >verify the name and domain in the original message that follows.
> >Message was addressed to: SAMUEL.KAPLIN@warehouse.mn.org

Sam Kaplin's account @warehouse.mn.org is apparently gone, but his address is
still apparently subscribed to cypherpunks. Some combination of the headers
placed on outgoing list mail by majordomo@toad, and the mail-return header
interpretation policy enforced by the mailer daemon @warehouse, is causing
list mail bounces to get routed to the original message sender. (Arguing over
which site is "at fault" should probably be done somewhere like the 
list-managers list, or much better still, between the sites themselves.)

A week or two ago I forwarded a bounce message to cypherpunks-owner@toad, and
my mail bounced. I asked Eric about it and he told me he hadn't been able to
get into that account for a while (he's the list manager :). Maybe that's been
rectified now. In lieu of that, the most expedient solution to these things
is usually a well-forged unsubscription request to majordomo@toad for the
bouncing address. I think Anonymous claimed to have taken care of that a
couple of days ago, but apparently they didn't succeed.

(Sam K. announced a while back that he would be effectively dropping off the
face of the net....)