Re: newbie Q: "Stacked" public key algorithm

sorry for the stupid question. Up to now I was just a cryptography user
without really understanding the technique behind, but now I've a question
regarding a solution I'm looking for, a kind of "stacked public key

I'm having trouble figuring out what you are trying to accomplish.

When you're trying to assign serial numbers to alligators to limit
them to one bite each of your ass, it may be time to step back and
state that the original objective was to drain the swamp, and consider
that maybe you've gotten off track.

Image, a company has a public and a secrect key. Employes also have their
own key pair. The planned scenario is like that:

the employee (Alice) send her public key to the company.

the company "mixes" their own private key with the public key of Alice and
send it back to Alice. Let us call this the "mixed key"

A possible way to handle this: the company receives encrypted mail
encrypted with the company public key. The company then decrypts it,
and re-encrypts the message with the public keys of the employees who
are supposed to get it, and sends it to them. That is, assuming that
the objective is to distribute mail sent "to the company", not specific
employees, to the employees.

Alice can use this "mixed" key together with her own private key to read
messages with where encrypt with the company public key, means messages
What does "with where encrypt" mean?

which were "sent do the company".
Is that sexual harrassment, as in "boss does his secretary"?

But Alice should not be able to seperate the company private key again out
of her mixed key, so that she can't give the company private key alone to
somebody else without telling that she was the one who forwarded the
company secret key.

The company should worry about giving an employee the company private
key, as they can do all sorts of things, like sign fake press
releases or authorizations for money transfers, without giving it
to anyone else.

Leak detection is generally done by hiding variations in subtle
places, like the low-order bits of images, differences which can
be detected in the copies. It's generally desirable for the recipient
NOT to be able to find the code at all (or they can remove it), and
especially NOT to be able to change the code to frame someone else.
The serial number might be encrypted with the company public key
so only they can figure out whose copy leaked when it's found posted
on the Internet. Remember, any two recipients can conspire and find
the differences in their two copies of the documents.

In order to do leak detection, it's necessary for each employee
gets a *DIFFERENT* copy of the document (and I don't mean the
encryption which the employee will remove to read it). This would
appropriately be done when the company gets the document before it
forwards it to the employees.

There is no necessity for the person receiving the document to even
HAVE a key to do leak detection. They might be people outside your
company (e.g. a Congressman, a judge, a vendor to your company, a
supplier to your company, etc.) who do not have the same encryption
infrastructure you do.

Good question, isn't it?

Not really. You're very vague about your overall objective
and delve into public-key stuff too fast.