Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FileUtils.sign() does not support ECDSA #89

Closed
hinca opened this issue Mar 18, 2020 · 8 comments
Closed

FileUtils.sign() does not support ECDSA #89

hinca opened this issue Mar 18, 2020 · 8 comments

Comments

@hinca
Copy link

hinca commented Mar 18, 2020

When using an elliptic curve keypair, the the key algorithm is EC, but the signature algorithm is SHA256withECDSA.

Therefore the assumption that one can get the Signature like FileUtils:100 does not hold:

Signature sign = Signature.getInstance("SHA256with" + key.getAlgorithm());

@mordechaim
Copy link
Contributor

mordechaim commented Mar 18, 2020

What do you recommend as a catch all alternative? Perhaps allow passing the signature implementation to the signer method and a default overload with the current implementation?

@hinca
Copy link
Author

hinca commented Mar 18, 2020

That is a nice fallback/advanced possibility. However the suffix list is quite easily exhausted, so you might also choose to handle EC as an exception:

https://docs.oracle.com/en/java/javase/14/docs/specs/security/standard-names.html#signature-algorithms

(Sorry for fat fingers, closed by accident.)

@hinca hinca closed this as completed Mar 18, 2020
@hinca hinca reopened this Mar 18, 2020
@mordechaim
Copy link
Contributor

mordechaim commented Mar 18, 2020

Well, the JDK signature API is extensible and might extend to other implementations too. Can I safely assume that other then EC, all implementations have an exact corresponding SHA256with + implementation counterpart?

@hinca
Copy link
Author

hinca commented Mar 18, 2020

I don't think we can rely on that. But my thoughts are to either make the "auto-algorithm" robust enough to at support all standard ciphers (it's not far from that), or don't offer it at all and make the user always supply the algorithm name. (Which loses convenience.)

@mordechaim
Copy link
Contributor

mordechaim commented Mar 18, 2020

Or go between the lines and offer both.

@mordechaim
Copy link
Contributor

mordechaim commented Mar 18, 2020

The problem is that when we verify we also need the exact same algorithm used, and it gets tricky to pass around the user-provided algorithm.

@hinca
Copy link
Author

hinca commented Mar 18, 2020

Yes, I would support offering both with overloading.

It's correct that we need that on verify time as well, but won't the developer of the launcher know exactly what kind of key the provider of the business app config used? (I mean, they have to exchange the key, so why not also exchange its properties? It is usually also determinable from the beginning of the key string.)

We could also write that algorithm as an argument of the configuration XML for piece of mind.

@mordechaim
Copy link
Contributor

mordechaim commented Mar 30, 2020

I think I'll stick to simply check if algorithm is EC and append "DSA". If it will be requested otherwise I'll think of an advanced solution then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants