Backporting changes from 5.x to 2.x

[dodmi]

Hi @lieser,

I'm failing to backport your enhancements to Thunderbird 52. I'd be interested at least at backporting support for the new signature algorithm.
While Thunderbird 52 seems to recognize the signal words import and export, I get error messages, that they may only be used at top level. MDN says, they are fully supported in version 60 and later. So there seems no easy way to adapt your new file/object structure.

I guess I'll have to modify the third party files or copy over the code into the old files, which may be a copyright problem - and will make future backports harder and harder. So, I'd prefer another solution - or at least minimal changes in the module files.

Could you give me some hints, please?

[lieser]

Fortunately for you, the files I include are already an adaptation to ESM (the new module system unsung import/export key words)
The original library at https://github.com/dchest/tweetnacl-js is still "normal" JavaScript files. You could try loading them with Services.scriptloader.loadSubScript(), like it is done for the RSA files.

[dodmi]

Thank you for pointing me to this library.
The library included in dkim-verifier seems to be different from the latest version you pointed me to...
The first big difference is in the modL function, which seems to fix an issue with signature creation: dchest/tweetnacl-js@af1919c
But as you only verify signatures, it's probably no issue for dkim-verifier.

I'll try my best to update dkim-verifier 2.x.

[lieser]

I also noticed that the fork I decided to use is missing a few newer commits. And came to the same conclusion as you, that it should not be relevant for verification.
But still thanks for letting me know about it.

[dodmi]

I'm sorry to bug you again, but it seems, I don't get it right.
In addition to the tweetnacl library, you pointed me, I'm using the recommended tweetnacl-util to convert the strings as described in the readme.
But I get bad signature errors.

I'm using the same arguments you provide for rsa verification:
key [the public key], str [plain text message], signature
For your test message, I'm setting key to yi50DjK5O9pqbFpNHklsv9lqaS0ArSYu02qp1S0DW1Y= and signature to 9/dsDChY0YMTtD5Eyw3wx7x22BlSJP7M5ECbJ7GWrR45nXlTCGb8l0YB
o0wBLR++X5LqmsxXaOYLLJe46l10AQ==

I've tried (as your hashing the data argument in crypto.js in DKIM-Verifier 5.x);

NaCl.nacl.sign.detached.verify(
          NaClUtil.nacl.util.decodeBase64(dkim_hash(str, "sha256", "b64")), 
          NaClUtil.nacl.util.decodeBase64(signature), 
          NaClUtil.nacl.util.decodeBase64(key)
);

I've also tried with the plain message (as it's done in DKIM-Verifier 2.x for RSA, but seems wrong for ed25519):

NaCl.nacl.sign.detached.verify(
         NaClUtil.nacl.util.decodeUTF8(str), 
         NaClUtil.nacl.util.decodeBase64(signature), 
         NaClUtil.nacl.util.decodeBase64(key)
);

Here are the added debug messages (in case I've made some typos...):

Could you please give me some hints. Testing here is really hard, as tweetnacl is a black box to me.

[lieser]

Could you try with the data form the RFC instead? https://www.rfc-editor.org/rfc/rfc8463#appendix-A. What is also what I am using for my test.

In a quick test with the data from the older draft version signature verification fails for me too. And not just for the ed25519 signature, but the rsa one fails verification too.

[dodmi]

Thank you very very much for pointing me to "better" test data. It's working fine with the data from the RFC.

[lieser]

You might want to backport the fix for revoked keys bf53899