how vulnerable is "hidden-encrypt-to"

[Jens Lechtenboerger]

On Sa, Aug 18 2012, Daniel Kahn Gillmor wrote:

> On 08/17/2012 11:16 AM, Hauke Laging wrote:
>> Am Fr 17.08.2012, 09:56:56 schrieb auto15963931:
>>> or what key ID
>>> had been used in conjunction with that option? Thanks.
>> 
>> You need the private recipient key in order to find out that key
>> ID. It's the  use of this option that you cannot get this
>> information in another way.
>
> It's worth observing that you can still detect the algorithm used
> and the size of the key, even when the keyid is all zeros.  So if
> someone has a particularly unusual key size (or is an early
> adopter of an unusual key type, like ECC), the pool of possible
> known recipients could actually be pretty small.

In addition, as explained by Barth et al. in 2006 in
http://www.adambarth.com/papers/2006/barth-boneh-waters.pdf 
"When GPG generates an ElGamal public key, it does so in the group
of integers modulo a random prime. Thus, different principals are
very likely to have public keys in different groups, making GPG
encryptions vulnerable to passive key privacy attacks. [...]
GPG could defend against these attacks by using the same prime for
every public key, for example one standardized by NIST"

What is the state of this recommendation?  Has it been implemented?

I'm not a crypto expert but I also think the following:
Encryption is performed symmetrically using a randomly generated
session key K, that is encrypted to the public keys of all (hidden)
recipients.  Thus, if a message M is encrypted to you and other
recipients using RSA, then you are of course able to obtain the
session key K.  Now, if you suspect Alice to be a recipient then you 
download her public key from a key server and encrypt the session
key K under her public key.  If the result matches one of the
encrypted session keys contained in M, then Alice is a recipient of
M.

If I'm not mistaken this attack works with RSA but not with ElGamal
(as ElGamal does randomized encryption).

Best wishes
Jens