consider removing the default maximum key size limit

[yogo1212]

there is a limit on RSA keys when using from_public_key_pem (returning KeyMalformed).

sadly, there are situations where its not feasible to either 1. use the *_with_max_size (because of using an external crate, like jsonwebtoken) or 2. change the infrastructure (company policy).

luckily for us, there's a workaround: using aws_lc_rs instead of ring circumvents the problem by not using the code.

in #210, it was noted that raising the limit is an option. personally, i don't think that the default limit is sensible. most applications don't read public keys from outside sources (preventing a DoS somehow implies an attacker, or not?).

when a key is loaded from an external source, it can reasonably be expected to verify the key. i'm of the opinion that the caller is responsible to specify a limit when loading a key from a potentially adversarial environment. they would have to be mindful of that any way.

it is easy to add an extra check before calling the primitives but it's rather difficult to take back a check that is built into the primitive.

[tarcieri]

use the *_with_max_size (because of using an external crate, like jsonwebtoken)

What size keys are you actually dealing with? We could perhaps raise the default upper limit to something like 8192.

You could also request an upstream option to bypass the check.

luckily for us, there's a workaround: using aws_lc_rs instead of ring circumvents the problem by not using the code.

I assume you meant the rsa crate for the latter here? I suppose it's interesting that aws_lc_rs has no such limit by default (or perhaps it's just higher).

most applications don't read public keys from outside sources (preventing a DoS somehow implies an attacker, or not?).

Many applications that perform public key cryptography do in fact have to deal with keys with potentially malicious keys. It's a problem for any openly federated system, like the web, or PGP, or age...

i'm of the opinion that the caller is responsible to specify a limit when loading a key from a potentially adversarial environment

That's what the API is trying to do, but you seem to want the default to be insecure rather than secure.

[Nielsen642]

Hi, Friedel
I came across this project on gitHub and found it really interesting.
I am full stack developer and I'd love to contribute
Would you be open to collaboration?

[Nielsen642]

Thanks for the detailed discussion here this is an interesting trade off.

I agree that enforcing a strict default limit at the primitive level can be restrictive, especially for applications that don’t operate in adversarial environments or rely on external crates where configuration isn’t easily adjustable.

One possible middle ground could be:

• Keeping a reasonable default limit for safety
• But allowing an opt-out or feature flag to disable/override it more easily (without requiring alternative backends like aws_lc_rs)

This would preserve security-conscious defaults while giving more flexibility to advanced users and constrained environments.

Curious if something like that was considered or if there are concerns around exposing such configurability?

[tarcieri]

We already provide explicit APIs to opt out of the checks.

A "feature" to disable default safety checks sounds like an anti-feature.

What I'd really rather get an answer to is who is hitting these limits in practice with legitimate keys and what the sizes of those keys actually are. We can raise the limit if need be.

[yogo1212]

@tarcieri the problem lies in the inability to use the "APIs to opt out of the checks" through dependencies without corresponding options. even if the key is loaded in the application rather than the dependency, the dependency still needs to offer a way of loading the key from an external source.

maybe there is an internal API but, at least in my last case, that would have meant writing the surrounding code myself. this would've shifted the application into "rolling your own crypto" territory - also not good for security.

for jsonwebtocken which is also "noble" and limits the list of algorithms, that is simply not possible. i can't implement an Algorithm trait myself or extend the enum in the crate.

an upper key length restriction just isn't something you would expect. these kinds of restriction, in general, are difficult to apply so broadly, so deep in the stack. you also can't lift the burden of thinking about attacks like the DoS scenario, anyway, and suggesting otherwise could be an issue in and of its own.

the very least, you could turn the KeyMalformed into a KeyTooLong error so people don't have to dig too deep through their applications. your design choice appears to have wasted countless hours of engineers - it took me at least a day of trying to figure out what the alleged error in my key material was, testing and looking at different stacks to see what they did differently.

btw, the key length that urged my employer to switch to aws' implementation was 8192 bytes long.

[tarcieri]

Thank you for finally confirming the key size you're using. We can raise the maximum key size to 8192-bits.

Our libraries are generally developed with a philosophy of misuse resistance when possible. If we can prevent DoS attacks like RSADoS, we should. Other libraries aren't necessarily developed that way.

I'm sorry this prevented you from using an 8192-bit key and that it caused confusion. KeyMalformed specifically comes out of the PKCS#8 parser, where perhaps we could use some more fine-grained errors.