Public Keys: add note about dangers of letting randos load keys

docs/publickeys.md

@@ -7,6 +7,8 @@ title: Overview
 
 Elliptic Curves are the best practices solution for both signature creation / verification and for diffie-hellman key exchange. The specific curves that you ought to be using for signing are Ed25519 (for 128-bit comparable security) or Ed448 (for 256-bit comparable security). For diffie-hellman key exchange the curves that you ought to be using are Curve25519 (for 128-bit comparable security) or Curve448 (for 256-bit comparable security).
 
+Also, doing anything with public / private keys from randos on the internet is ill advisable. Loading keys and performing cryptographic operations on a [16384-bit RSA key](https://stackoverflow.com/a/39069182/569976) may be suitably performant on a system with the latest Intel i9 processor and the [GMP extension](https://www.php.net/gmp) installed but what about a Raspberry Pi without either OpenSSL or GMP? phpseclib is designed to be able to operate on both, after all. Maybe dynamic guardrails could be put in place to scale the maximum supported key based on your system specs but, then again, what if you're using phpseclib to connect to an SSH server with an RSA key from behind a password protected admin control panel? Maybe authentication takes 20s because of your system specs and the key you're using and maybe you're okay with waiting that long. That's a perfectly valid use case. On the flip side, if a rando on the internet can send an HTTP request that'll eat up 20 seconds of compute time then that makes it a lot easier for an attacker to perform a [DOS attack](https://en.wikipedia.org/wiki/Denial-of-service_attack) if they were to flood your server with a bunch of said HTTP requests over the span of, say, 30 seconds. Ultimately, phpseclib has no control over how it's used and phpseclib isn't going to neuter valid use cases to safeguard against invalid use cases.
+
 ## Loading Keys
 
 The recommended way to load public keys is to do so thusly: