fix(ffi): validate JWK base64url encoding

[mfazrinizar]

Summary

Fixes #328.

The shared FFI JWK decoder currently accepts padded values and characters from the standard Base64 alphabet.

This PR validates the decoded value by re-encoding it as canonical unpadded base64url and comparing it with the original input. It therefore rejects:

• explicit Base64 padding
• the standard Base64 alphabet
• other non-canonical encodings

The regression tests use HMAC JWK import as a representative public API path. The decoder is shared by the FFI HMAC, AES, EC, and RSA implementations.

Testing

Verified with:

• dart format --output=none --set-exit-if-changed .
• git diff --check
• dart analyze
• dart test test/webcrypto_test.dart -p vm -n 'JWK: rejects'
• dart test test/webcrypto_test.dart -p chrome -n 'JWK: rejects'
• dart test test/webcrypto_test.dart -p vm
• dart test test/webcrypto_test.dart -p chrome

[mosuem]

I am a bit torn, this seems to be quite a heavy way to do the check - re-encoding does more work than is actually necessary. But then again we can always make it faster later...

[mfazrinizar]

I am a bit torn, this seems to be quite a heavy way to do the check - re-encoding does more work than is actually necessary. But then again we can always make it faster later...

I think that’s fair. The round-trip check was considered because it makes canonical unpadded base64url validation simple and difficult to get wrong, but it does add another encoding pass, allocation, and comparison.

Maybe a more efficient version would validate the URL-safe alphabet, length, and unused final bits directly in one pass, then add padding and decode once. Since this only runs during JWK import and the inputs are relatively small, I agree it is not urgent, but we can replace it with the direct validator later if this becomes worth optimizing.