In fact, I mention the SEE in my package's documentation. If you have a license to the paid extension, it should be easy to compile it and use it with my package.
It will be slow, however, because it will be running the reference AES implementation in Wasm.
That said, if anyone is interested in sponsoring a SEE license, I can look into doing the encryption Go (which uses assembly on most platforms for those bits).
But the only versions mentioned in [1] that should compile out of the box into Wasm, are the ones that say they use "the Rijndaal reference implementation."
I don't think compiling OpenSSL into Wasm is tenable. But some wrappers around the Go AES implementation should work.
That was a complete surprise to me.
Here’s the relevant link:
https://sqlite.org/prosupport.html
Of course, nor would I expect them to make it so.
In fact, I mention the SEE in my package's documentation. If you have a license to the paid extension, it should be easy to compile it and use it with my package.
It will be slow, however, because it will be running the reference AES implementation in Wasm.
That said, if anyone is interested in sponsoring a SEE license, I can look into doing the encryption Go (which uses assembly on most platforms for those bits).
Which reference AES implementation? My memory is that the one from the spec has terrible timing side channel attacks... e.g. https://www.redhat.com/en/blog/its-all-question-time-aes-tim... seems to corroborate my memory.
I seem to recall this was remotely exploitable, and exploiting timing side channels has only gotten better since 2014.
I don't have a license, so can't know for sure.
But the only versions mentioned in [1] that should compile out of the box into Wasm, are the ones that say they use "the Rijndaal reference implementation."
I don't think compiling OpenSSL into Wasm is tenable. But some wrappers around the Go AES implementation should work.
[1] https://www.sqlite.org/see/doc/release/www/readme.wiki