Closed CMCDragonkai closed 4 years ago
Using NaCL is different from using Node crypto as node crypto relies on openssl. And course openssl is not available in browsers, which instead provide webcrypto. But at the same time, that means the crypto is running in JS, and not relying on native APIs.
This choice is really important because it informs the usage of the same library across all other Polykey components. And it has a high security importance.
Peculiar Ventures has several webcrypto
libraries with subtle differences that I will try to elucidate here. The 3 are:
node-webcrypto-p11
seems to have a whole bunch of functionality surrounding hardware security modules (i.e. the PKCS#11 standard) which we don't need. node-webcrypto-ossl
is 'a native polyfill for WebCrypto based on OpenSSL'. Both of these seem to come with key storage capabilities. I think the one we want is webcrypto
.
All of these libraries depend on their webcrypto-core library
It's true that nativescript doesn't expose a node.js like crypto
library but it looks like this is on the horizon for development: https://github.com/NativeScript/NativeScript/issues/195
Something we could do in the mean time is use nativescript-nodeify
So from discussion, it has been decided to make EFS isomorphic with respect to crypto library in order to maintain maximum flexibility when using EFS in other platforms. EFS will expose an optional parameter of crypto: CryptoInterface
and CryptoInterface
will only require the methods we actually use in EFS. The default implementation if no crypto library is provided will be webcrypto
ATM this is using Node crypto. This is not portable to the other systems that we intend to use js-encryptedfs with.
Now this isn't using PGP, so we don't use kbpgp or openpgp.js. However we are using AES.
It seems we have a couple of choices here:
I'm not sure if the NaCL library fits our requirements.
Furthermore nativescript will require a completely different implementation too. So we would likely need to tackle that later.