It would need to be a 3, 5, or 7, since a prime is required.
Note that p,q (the primes you’re thinking of) are not actually required for decryption. They enable you to calculate d, the decryption exponent, and also enable decryption-time optimizations (exponentiation with d_p and d_q followed by CRT recombination), but that’s optional. In fact, p,q can be computed from n, e and d.
q=82392744353585332429460820191121154258120959554076291572887591391377445536703
n=6961473881062880999817189307002435362675293718841800458853975151946795609411283948376850761685158526939121778595276868395992041449207352173613540433589369
e=1305276352699290187465722995062956630501617572282837586035120340990024176764584449553695476096002966088824142338449519554315283866861919281309484272012046
d=4
assert n == p * q
assert pow(pow(123456789, e, n), d, n) == 123456789
(This doesn't work for all messages `m`, so I agree with what you've said - d=4 is not a good choice. But it can work.)
Every definition of RSA I've ever seen requires d and e to be coprime with λ(n)
This feels a bit like an EC25519 definition suggesting that "private keys must be significantly larger than 4" and therefore you call what eMudhra generated "modified EC25519"
Also note that using small numbers like 65537 for RSA public exponents is common practice.
Like, that had to be malicious right? ssh-keygen won't generate a key like this, and neither will openssl or whatever Microsoft is doing behind their CA server.
shrug
I think they're just absolutely inept and should never be trusted with anything security related as an organisation if this is a mistake they could make.
The "4" would be valid in hex, decimal, and even octal.
The key needs to mention which curve it is using.