Repository navigation
v6.1.0 computeSignature() causes DeprecationWarning #497
Description
Activity
We are aware and welcome PRs to address this.
- changed the title
[-][BUG]: v6.1.0 computeSignature() causes DeprecationWarning[/-][+]v6.1.0 computeSignature() causes DeprecationWarning[/+]on Apr 18, 2025 @strawberrycz Have you tried using: https://nacl.cr.yp.to/box.html
That's a library designed by experts for cryptography.
You can just sign the XML serialized as a string, and then re-parse it later. It's ugly, but XML-Crypto also serializes and re-parses.You shouldn't rely on xml-crypto for any security related stuff, you would be endangering your users.
@ahacker1-securesaml , is it possible to provide a clear way to use NaCl Box for users. That link you sent doesn't have any instructions for use in a Node project. It also doesn't have directions on how to use it on Windows. If NaCl Box won't work for users of xml-crypto, and someone has to work with XML for project-specific reasons (SAML, SOAP, et.c), what alternative would you suggest?
Google and ChatGPT is there to help.
Anyways, NaCl works for any data, so you can just sign the raw xml as a string. Ie signing the soap body as a xml string, then client reparses it later.Many more secure ways of signing data then using xmlcrypto . Suppose a new attack comes out against rsa signatures, xml signatures libraries won't be able to mitigates it because don't have active maintainers.
Better to switch now then later
@ahacker1-securesaml FWIW this issues example code at description seems to/might be the case of signing Czechia flavour of electronic prescription which seems to be related cz's domestic and European Union's cross border (EU wide) electronic prespriction. I.e. possibility to exchange EU citizens' prescription from one country to another to get public health care services at EU area regardless of current location or something like that.
Feed
ZalozeniPredpisuDotaz(term was taken from issues descriptions example code) to your favourite search engine and you might end up here https://epreskripce.gov.czIf you want to dig little bit further you might want to use your favourite search engine with search terms
electronic prespriction eu.Point of this comment was that one can find e.g. healthcare, finance and corporate specs which use xml digital signatures for other purposes than SAML. E.g. digitalization of healthcare systems are slow from every possible aspect (specification phase and adaption of specifications) so unfortunately xml dsig usage is more like increasing in terms of systems which use it instead of fading away.
This comment was also indirect response to comment #493 (comment) :
For SAML implementations, we can still support xml-crypto
Reacted by Chris BarthPoint of this comment was that one can find e.g. healthcare, finance and corporate specs which use xml digital signatures for other purposes than SAML. E.g. digitalization of healthcare systems are slow from every possible aspect (specification phase and adaption of specifications) so unfortunately xml dsig usage is more like increasing in terms of systems which use it instead of fading away.
Yes there are legitimate cases outside of SAML, but I want to make the case that migrating away from XML Signatures is the best move for the smaller applications.
First of all, signing XML using XML Signatures is basically useless, as you cannot guarantee that the receiving side will actually use the signed portions.
Most clients will likely be vulnerable to either signature exclusion attack & signature wrapping attacks. Maybe we did secure xml-crypto verification, but all the other libraries are vulnerable.
To mitigate the attacks is to used the signed portions i.e. for xml-crypto use getSignedReferences(). At that point if the client has to refactor their code logic to use the signed portions, then they might as well just migrate away from XML Signatures entirely.
Furthermore, there isn't any active development on the XML Signature specification. There weren't any cryptographers to design the specification in the first place, and I doubt they will help out in the future.
For example, one of the main issues is post quantum cryptography, i.e. issues with RSA Signatures and how they can be broken.
Who is going to write a specification & implementations & migration plan for post quantum cryptography algorithms?
That's going to take a lot of human hours.
It's insulting to crytographers because they built one of the most secure cryptographic APIs i.e. libsodium CrytoBox, and have repeatedly warned users not to roll their own crytographyEU has already mandated migrating away from RSA and towards secure algorithms like ECC. Note that this library does not support ECC
Migration to LibSodium
It's simple: For HTTP Requests, sign the request body using libsodium/ECC crytography.
For XML Documents/SOAP, libsodium returns a base64 encoded data:
base64.signatureJust embed it within the existing data:
<Prescription> libsodium: base64.signature </Prescription>
EU Regulatory problems
You are correct EU is slow to adopt changes, so maybe libsodium isn't approved yet (despite it actually designed by crytographers).
That is a problem with EU eIDAS standard. We shouldn't support/encourage XML signatures because some bureaucrat with no knowledge of cryptography mandates that usage.
Instead we should make a convincing case against XML Signatures and on towards libsodium/PASETOs.Furthermore, it seems like these eIDAS standards are not contributing to security. We should impose charges for legacy support for the insecure XML signing/verification, on bureaucracies like eIDAS. AND donate them to active cryptographic research.
Issue Description
v6.0.1 is OK, but in v6.1.0 I am getting DeprecationWarning when computeSignature() is called.
Code Snippet
Additional Context