3 ms·
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 sho
by ncruces 3y ago
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).
- cipherboy 3y agoWhich 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-timing-attacks-openssl 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.
- ncruces 3y agoI 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 https://www.sqlite.org/see/doc/release/www/readme.wiki