3 ms·
This is very timely for me. Only two weeks ago, I learned that the bouncycastle Java FTP client library refuses to talk to servers that run with custom dh_param
by pilif 3y ago
This is very timely for me. Only two weeks ago, I learned that the bouncycastle Java FTP client library refuses to talk to servers that run with custom dh_params and I was wondering why because my intuition told me that custom parameters should be better than parameters shared between everyone.
And now only two weeks later, I get a very good explanation as to why, like often in crypto, intuition was wrong
- schoen 3y agoThere can also sometimes be more specialized reasons than the general considerations given in this article. I forgot now whether it was DH or RSA or both, but there was a toy attack where interacting with a peer with super-bad maliciously-chosen parameters can also create an oracle for attacking the same party's simultaneous interactions with a third party, if the same secrets are used in both conversations. Sorry for the lack of details, I just totally forget them. I know I did something like this in a CTF, though. A vaguely related example could be that nonce reuse in DSA/ECDSA signatures can leak the signing key, so a DSA signer must not allow the other side to choose the nonce. That isn't conventionally seen as a "parameter", but it's easy to imagine that an implementer wouldn't automatically assume that it's actively dangerous to let the other party choose it.
- tptacek 3y agoFamously, small subgroup attacks in DH; I can't think of non-silly RSA parameter negotiation bugs (I mean, E=1 with SaltStack, but that doesn't really count). Invalid point bugs in ECDH and zero-mod-p in PAKEs are similar in spirit, but don't really derive from parameter negotiation.