Repository navigation
[ENHANCEMENT]: ECDSA Support #530
Description
Is your feature request related to a problem? Please describe...
Hi there, I am in need of a SAML testing toolkit that can create SAML Responses that are signed and encrypted with ECSDA (going off the definition from the xmldsig-core spec).
I noticed this library doesn't seem to have support for that! (only RSA algs). Is ECDSA support something you would be interested in adding?
Describe teh solution you'd like...
I was able to monkey-patch in ECDSA support by just leaning on the node.js crypto engine to notice that my provided privateKey is an EC key instead of RSA. This kicked in by removing the RSA- in the call to crypto.createSign in signed-xml.ts, so:
- Instead of
var signer = crypto.createSign("RSA-SHA256") - Calling
var signer = crypto.createSign("SHA256")
I realise that seems a bit fragile, and there are ways that we could pre-parse the provided key instead. Do either of those approaches seem acceptable?
At the same time I could poke around at moving to web-crypto instead.
PS - I have a bit of history with Applied Crypto. I cut my teeth on more JWT work, but in my day job I have had to support / implement SAML a lot and am looking to update our systems from RSA to ECDSA.
Describe the alternatives you've considered...
Right now this library is hard-coded NOT to support the http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 algorithm. So no alternatives unless there is a bring-your-own-alg option I missed?
Activity
madaster97 commentedon Jan 30, 2026
FYI I am looking into this further and it looks like node.js outputs in ASN.1 encoded
r , sinstead of IEEE-P1363r || sby default. Should be a quick fix using theieee-p1363flag ofdsaEncodingoncrypto.signKudos to this example dotnet implementation with an example
SignatureValueYou can check if your Sig Value is parsing correctly using this CyberChef recipe, AND confirm it is incorrect using this one (only incorrect /
r , sones parse)PS - Just quoting the spec because it confused me