[Bug]: Actual only supports RS256 #2759

New Issue

GiteaMirror · 2026-02-28T20:26:58-06:00

GiteaMirror commented

2026-02-28 20:26:58 -06:00

Originally created by @TheRealGramdalf on GitHub (Jan 2, 2026).

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

When setting up Actual server with my IdP, it did not initially function due to the cryptography in use. I needed to switch my provider from ECDSA to RS256 for the flow to complete.

This issue is a duplicate of #5537, but it is marked as a feature request which causes the issue to be closed. This issue is intended to remain open for visibility, as ECDSA should be a goal heading forward.

For the rationale, see this FAQ entry from my provider, Kanidm:
https://kanidm.github.io/kanidm/stable/frequently_asked_questions.html#why-is-rsa-considered-legacy

While RSA is cryptographically sound, to achieve the same level as security as ECDSA it requires signatures and keys that are significantly larger. This has costs for network transmission and CPU time to verify these signatures. At this time (2024) to achieve the same level of security as a 256 bit ECDSA, RSA requires a 3072 bit key. Similarly a 384 bit ECDSA key requires a 8192 bit RSA for equivalent cryptographic strength, and a 521 bit ECDSA key would likely require a 16884 bit RSA key (or greater).

This means that going forward more applications will require ECDSA over RSA due to its increased strength for significantly faster and smaller key sizes.

Where this has more serious costs is our future desire to add support for Hardware Security Modules. Since RSA keys are much larger on these devices it may significantly impact performance of the HSM and may also limit the amount of keys we can store on the device. In the case of some HSM models, they do not even support RSA keys up to 8192 bits (but they do support ECDSA 384 and 521). An example of this is TPMs, which only support up to 4096 bit RSA keys at this time.

As a result, we want to guide people toward smaller, faster and more secure cryptographic standards like ECDSA. We want to encourage application developers to implement ECDSA in their OAuth2 applications as it is likely that limitations of RSA will be hit in the future.

Generally, it’s also positive to encourage applications to review and update their cryptographic implementations over time too. Cryptography and security is not stangnant, it requires continual review, assessment and improvement.

How can we reproduce the issue?

N/A

Where are you hosting Actual?

Other

What browsers are you seeing the problem on?

Other

Operating System

Other

Originally created by @TheRealGramdalf on GitHub (Jan 2, 2026). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? When setting up Actual server with my IdP, it did not initially function due to the cryptography in use. I needed to switch my provider from ECDSA to RS256 for the flow to complete. This issue is a duplicate of #5537, but it is marked as a feature request which causes the issue to be closed. This issue is intended to remain open for visibility, as ECDSA should be a goal heading forward. For the rationale, see this FAQ entry from my provider, Kanidm: https://kanidm.github.io/kanidm/stable/frequently_asked_questions.html#why-is-rsa-considered-legacy >While RSA is cryptographically sound, to achieve the same level as security as ECDSA it requires signatures and keys that are significantly larger. This has costs for network transmission and CPU time to verify these signatures. At this time (2024) to achieve the same level of security as a 256 bit ECDSA, RSA requires a 3072 bit key. Similarly a 384 bit ECDSA key requires a 8192 bit RSA for equivalent cryptographic strength, and a 521 bit ECDSA key would likely require a 16884 bit RSA key (or greater). >This means that going forward more applications will require ECDSA over RSA due to its increased strength for significantly faster and smaller key sizes. >Where this has more serious costs is our future desire to add support for Hardware Security Modules. Since RSA keys are much larger on these devices it may significantly impact performance of the HSM and may also limit the amount of keys we can store on the device. In the case of some HSM models, they do not even support RSA keys up to 8192 bits (but they do support ECDSA 384 and 521). An example of this is TPMs, which only support up to 4096 bit RSA keys at this time. >As a result, we want to guide people toward smaller, faster and more secure cryptographic standards like ECDSA. We want to encourage application developers to implement ECDSA in their OAuth2 applications as it is likely that limitations of RSA will be hit in the future. >Generally, it’s also positive to encourage applications to review and update their cryptographic implementations over time too. Cryptography and security is not stangnant, it requires continual review, assessment and improvement. ### How can we reproduce the issue? N/A ### Where are you hosting Actual? Other ### What browsers are you seeing the problem on? Other ### Operating System Other

GiteaMirror added the openid bug help wanted labels 2026-02-28 20:26:58 -06:00