How could you disclose what you like and have someone respond with what you want without revealing who you are? Bob likes Apples and Oranges (virtual, not physical). Alice and Eve are fruit sellers (again, virtual, not physical). Bob wants to indicate his appetite to buy one Apple and one Orange without revealing who he is. Alice and Eve want to sell to Bob but they can't know Bob's identity. How does Bob communicate his preference to buy, and then take receipt, without Alice and Eve ever knowing who he is and without using a central authority?
All Bob needs is to generate an Ephemeral key: just make (say) an RSA key, use it to initiate and proceed with communications with Alice, then delete it when he's done, taking care never to use it to process any personally-identifying information.
In fact, this is what web browsers do every time you connect to a website: by default, only the server has a certificate anchoring its identity; clients are anonymous until or unless they supply authentication. Your queries to, say, Searx are confidential, known only by the host and the anonymous client which started that TLS session.
(The bit about &quot;no central authority certifying Alice&quot; is a massive, separate question -- it is the puzzle which X.509, DANE, and an entire host of decentralized proto-solutions are still struggling to solve to this day; but I'll include a proto-solution to it as well.)
With any public-key cryptosystem, it's trivial to implement an ephemeral or &quot;anonymous&quot; key, by simply not attaching identity attestations to a freshly-generated public key and then throwing it away afterwards; if you're only concerned with the authenticity of one party (Alice is a recognized fruit seller or someone whom Bob otherwise knows the public key of; Bob is an anonymous client with no identity persisting beyond the scope of a single discussion session), it's quite easy -- For example (all messages listed are both signed by the sending key and encrypted by the receiving key):
Bob: (Acquires Alice's putative pk_A)
Bob: (Generates a keypair sk_B, pk_B)
Bob -&gt; Alice (sk_B -&gt; pk_A): &quot;Buying oranges for 3 bitcoin, reply-to [pk_B]&quot;
Alice -&gt; Bob (sk_A -&gt; pk_B): [initiate zero-knowledge proof of orange possession]
Bob -&gt; Alice (sk_B -&gt; pk_A): [challenge proof]
Alice -&gt; Bob (sk_A -&gt; pk_B): [complete proof]
Alice -&gt; Bob (sk_A -&gt; pk_B): &quot;send 3 bitcoins to [btc_A] if you want them&quot;
Bob -&gt; Alice (sk_B -&gt; pk_A): [transaction]
Alice -&gt; Bob (sk_A -&gt; pk_B): [oranges]
Bob: (deletes sk_B and all trace of pk_B off his computer)

In the real-world, something like this happens if you buy something from an online merchant using a burner e-mail (or no e-mail) and either General Delivery or inherently digital data served over the same TLS connection, though without a &quot;proof&quot; of the online merchant's legitimacy (which, again, is a whole separate scope from merely allowing bidirectional secure communications with an anonymous participant).

[Note that Bob and Alice are switched from their canonical roles in your question; I have written my answer to reflect that, but, in the future, you should use &quot;Alice&quot; to represent the initiator/sender of communications and Bob as the recipient or secondary participant. Additionally, &quot;Eve&quot; is used to denote the malicious party -- the hacker or &quot;Eavesdropper&quot; -- who may be just eavesdropping, or may be launching interactive or invasive MitM attacks; her abilities are generally assumed to comprise control of the network.]