Maybe. I haven't tried it. Someone actually suggested this to me on the #gnupg IRC but I just kinda forgot about it.
The --export-secret-subkeys command does just that: it replaces the master key with some GNU specific stub packet thing. It's conceivable that they could detect this and reject the uploaded key. In order to avoid that, one might edit the secret key packet manually instead. Just zero fill or randomize all the secret key bits or something. I assume it wouldn't match up with the public key though. Aren't the public and private keys mathematically related? Maybe you can detect that the key is bogus if you try to do cryptographic operations with it. Maybe the operation somehow fails or produces nonsense results. I don't really know enough cryptography to say.
Indeed filling the private key with zeros or random data wouldn't work, but we do support GNU Dummy keys as exported by `gpg --export-secret-subkeys` nowadays.
RFC4880 uses ElGamal for the asymmetric encryption and so it's a discrete log problem. Roughly the private key x should satisfy `a=b^x mod n` where b and n are known, and a is part of the public key. It goes through similarly for elliptic curve-based schemes.
FWIW, OpenPGP doesn't only offer ElGamal, and we never use that algorithm. We use Curve25519 by default since quite a while, before which we used RSA. We've never used ElGamal and also don't allow importing ElGamal keys, since they're insecure and deprecated in the crypto refresh (the upcoming update to the OpenPGP standard): https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-cry....
Good point, I just picked the simplest example. In fact I use Proton for my personal email and wouldn't dream of it if I didn't think your crypto was up to scratch.
