Nice puzzle but the problem seems to be reduced to a problem of safely distributing keys, in this case behind the menu (what if I'm in another country?). Also, it's similar to one-time pad [1] where you generate a random key with same length as the message and XOR them. This achieves perfect secrecy with the question on how you distribute keys.
> but the problem seems to be reduced to a problem of safely distributing keys,
That's just a standard problem for asymmetric cryptography.
Each person at the table announces a public key. Each party can now derive a shared secret with each other party using diffie-hellman. The shared secret can be used to produce a pseudorandom stream using a CSPRNG or stream cipher.
One doesn't need to use trusted third parties to use public keys.
In fact, the most popular existing TTP public key infrastructure provides extremely limited security (someone who can intercept http near an IP where your domain name resolves can easily obtain an SSL cert with your domain name on it).
I'm not sure what you'd call it other than man-in-the-middle.
The issue is that CA's (for various defensible reasons-- including that there isn't much better possible within their framework, it's not like they know you personally...) will issue a cert for your domain to any party that can throw a file up on it that their automation fetches via http.
In practice this means a MITM near your server (or, technically, anywhere between any CA that will issue certs for your domain and your server), or between your CA and the DNS results can get certs for your name and there isn't much you can do about it.
Naively, this seems analogous to differential privacy, where the distribution of the result is the same as the real one, without revealing the individual elements - or is the dining cryptographers a full proof? I couldn't quite tell on first read.
In general case DCnets provide perfect sender privacy (among participants, of course). If there are multiple messages their senders will be completely unlinkable.
Specific implementations might use schemes for collision resolution that break privacy, though there is no requirement that collisions (absent malicious participants) even be possible at all-- with fancy enough technology applied.
Dining cryptographers and their variants are usually fully proven in the sense that when all but one input is zero, you will receive the intended input. You always receive the combination under the operation you are using (i.e. xor of all messages).
[1] https://en.wikipedia.org/wiki/One-time_pad