Skip to content

Commit b2acaf9

Browse files
committed
PublicKeys: tweak working
1 parent b68e394 commit b2acaf9

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/publickeys.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ title: Overview
77

88
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).
99

10-
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.
10+
Also, doing anything with public / private keys from randos on the internet is ill advisable. For example, 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.
1111

1212
## Loading Keys
1313

0 commit comments

Comments
 (0)