React Native and Mobile OS (iOS and Android) Compatibility

[joshuakarp]

Created by @CMCDragonkai

No js-polykey cannot be used in browsers. However for NS, we may need to polyfill alot of our dependencies.

The js-polykey doesn't need to do this. But in Polykey-NativeScript we are going to we webpack5 and have to resolve some packages.

Webpack 5 no longer polyfills node core modules, but we can do it manually:

• https://github.com/Richienb/node-polyfill-webpack-plugin/blob/master/package.json
• webpack/webpack@a68426e

These are:

	assert: "assert",
	buffer: "buffer",
	console: "console-browserify",
	constants: "constants-browserify",
	crypto: "crypto-browserify",
	domain: "domain-browser",
	events: "events",
	http: "stream-http",
	https: "https-browserify",
	os: "os-browserify/browser",
	path: "path-browserify",
	punycode: "punycode",
	process: "process/browser",
	querystring: "querystring-es3",
	stream: "stream-browserify",
	_stream_duplex: "readable-stream/duplex",
	_stream_passthrough: "readable-stream/passthrough",
	_stream_readable: "readable-stream/readable",
	_stream_transform: "readable-stream/transform",
	_stream_writable: "readable-stream/writable",
	string_decoder: "string_decoder",
	sys: "util",
	timers: "timers-browserify",
	tty: "tty-browserify",
	url: "url",
	util: "util",
	vm: "vm-browserify",
	zlib: "browserify-zlib"

Some of these can be polyfilled for NS.

In other cases, we will need to write alternative implementations when they don't exist, like for example the usage of fs - https://docs.nativescript.org/ns-framework-modules/file-system

Related:

• Integrating PKCS #11 standard for accessing HSM #173
• Replace node-forge RSA Keypair With ed25519/x25519 Keypair #168

[CMCDragonkai]

In working on core activity 2 of our R&D report, I've discovered some prior context for this particular issue.

This comment #43 (comment) explains how we came to be using node-forge as opposed to other cryptographic libraries.

I know that when Polykey project first started, we initially were thinking of using PGP and thus the kbpgp.js library (https://github.com/keybase/kbpgp). We ended up going away from PGP due to its limited usage in a number of scenarios that we want PK to deal with. Namely end to end encrypted network communication which is a TLS issue, that makes use of X.509 certificates rather than PGP certificates. Furthermore we also had symmetric encryption/decryption scenarios like js-encryptedfs that again would not make use of PGP standards. Therefore it just lacked interoperability with many other cryptographic scenarios, it seemed like its own island of standards, the library can still be brought back in in the future if we find usecases for PK using PGP.

However in choosing node-forge, we came across a few other problems. Mainly overall-cross platform compatibility planning for mobile devices. This is not just a problem with crypto, but also other libraries that are used in our networking domain such as utp-native.

Here are something I found that may be relevant to us proceeding here:

• The webcrypto standard (https://w3c.github.io/webcrypto/) is now the official standard for cryptographic operations in browser environments. It is now being supported by all major browsers and electron
• This webcrypto standard is now taking over other deployment platforms such as in Nodejs: https://nodejs.org/api/webcrypto.html & https://www.nearform.com/blog/implementing-the-web-cryptography-api-for-node-js-core/
• As a standardised API, switching over to this API gives us more cross-platform opportunity as the rest of the world's development ecosystem catches up and migrates over to webcrypto standard.
• In particular are nativescript and react-native ecosystems. Currently none of them have official crypto APIs, they expect the developer to use underlying native iOS or Android crypto APIs.
• However I found out that the GUN project https://github.com/amark/gun#additional-cryptography-libraries claims to be able to use webcrypto on react-native and other platforms.
• It does this through a "webview" trick. Basically this hooks into the browser runtimes that are on iOS and Android to perform the actual crypto and then return the results back to the main application. I have no idea about the performance characteristics of this trick. This trick is described here: https://gun.eco/docs/React-Native and https://github.com/webview-crypto/react-native-webview-crypto
• The usage of webcrypto libraries is pioneered by "PeculiarVentures" which has these main libraries:
  • https://github.com/PeculiarVentures/PKI.js - this could be an alternative to node-forge for all of our PKI/X.509 and TLS related functionality (previously it was claimed this was overly complex compared to node-forge)
  • https://github.com/PeculiarVentures/webcrypto - this is a generic polyfill for webcrypto, not entirely sure how it wraps the native webcrypto inside nodejs or if smooths over the differences, there is a discussion about this library in relation to other webcrypto polyfills targeting nodejs https://github.com/PeculiarVentures/webcrypto, because this is also mentioned with respect to the webview trick, there may also be a relationship between the webview trick and this polyfill
  • They have many other crypto related libraries that we should investigate

All of this will mean that we either replace node-forge, or end up creating a adapter pattern where we plugin different crypto implementions depending on our environment. At this point in time, the keys domain abstracts over most(all?) crypto operations for all other domains. Except in the case of EFS which is currently pinned to node-forge (it may be a good idea to abstract that and expect an interface of functions for EFS).

Cross platform compatibility here isn't just about the fundamental crypto library. It's also about other parts of PK. One closely related situation is the JOSE libraries. As they involve cryptographic operations, they currently seem to "fix" their underlying crypto library as well. It would be ideal that if we standardise on a crypto library for cross-platform deployment, that we can also ensure that our JOSE library is using the same crypto library to reduce our crypto attack surface. We are currently using https://github.com/panva/jose which uses native crypto depending on the platform including webcrypto. Contenders include https://github.com/cisco/node-jose (which fixes on node-forge) and https://github.com/square/js-jose.

Still to research:

• utp-native and networking libraries
• others...?

[CMCDragonkai]

Regarding the future of using web assembly, here are relevant resources:

• https://www.fastly.com/blog/standard-cryptography-api-webassembly
• https://github.com/WebAssembly/wasi-crypto
• https://stackoverflow.com/questions/48891593/webcryptoapi-vs-webassembly-encryption-module
• https://medium.com/nexenio/a-random-story-on-webcrypto-and-webassembly-6f9e00c73a

The last link is interesting as it describes how to use webcrypto together with webassembly when you need a custom crytographic functionality not supported inside webcrypto.

[CMCDragonkai]

Another example of wasm and webcrypto usage:

• https://medium.com/cubbit/how-to-build-a-crypto-isomorphic-library-with-javascript-and-webassembly-6fc7aa708437
• https://github.com/cubbit/enigma and WASM in Enigma cubbit/enigma#16

[CMCDragonkai]

One note about WASM. There are 2 well supported runtimes for WASM:

• wasm3 - supports interpretation
• wasmer - supports JIT and AOT compilation

So that does mean wasmer can compile WASM code to native code. But wasm3 is for interpretation. Why use interpetation?

It appears that in some cases interpretation can be more widely deployed. There are examples of iOS apps using wasm3. https://github.com/kateinoigakukun/wasmic-ios

It's becoming fast a standard target for many languages. Even TypeScript when ported to AssemblyScript can be compiled to WASM.

Once it is WASM, the only thing missing is broad adoption of WASI. If WASI is broadly adopted like it is in nodejs (https://github.com/nodejs/uvwasi), then pretty much we have a universal portable binary capable of doing relevant system operations. WASI is like a universal standard of system calls. Like a whole new POSIX standard.

Then one would just use WASM and WASI for all platforms.

[CMCDragonkai]

Dynamic imports can be used to inject platform-specific implementation adapters.

async function test () {
  // dynamic imports work now!
  const p = await import('perf_hooks');
  console.log(p);
}

test();

So if we needed to supply different implementations for different platforms, we could do a feature/platform test, and then dynamically import the right module.

Important thing is that it is asynchronous, so it would have to be wrapped up in a class, or function.

TS compiler will translate the above into a promise that acquires modules using require in commonjs or other ways depending on the platform.

There is top level await in NodeJS as well, but I'm not sure it will work across all the platforms.

Could be important for all these areas:

• GRPC GRPC Web Proxy to enable Browser Integration and Eliminate Electron IPC #235
• Cryptography (web crypto)
• Networking Using QUIC/HTTP3 to replace utp-native for the Data Transfer Layer in the networking domain #234

Current attempt at using top level await to do this is located at the js-id work: MatrixAI/js-id#1 (comment). Notice that there's quite a few changes required, and we would need to prototype a working solution in TypeScript-Demo-Lib. I reckon, this is something that will require TS 4.5 to be released completely, and ts-node support in TypeStrong/ts-node#1007.