Investigate pure TS client-side implementation

[cygnusv]

trafficstars

Let's recall our current stack:

• ferveo: Core cryptographic implementation (Rust -> WASM)
• nucypher-core: Protocol API and objects (Rust -> WASM)
• taco-web: Adopter-facing API (TypeScript)

The scope of this issue is to investigate to what extent we can build a minimal substitution for ferveo and nucypher-core using purely TypeScript primitives. Since browser interactions are currently tied to the creator/encryption and consumer/decryption request steps, let’s investigate what happens underneath and what do we need to replace.

Encryption (taco/src/tdec.ts/encryptMessage()):

• nucypher_core::encryptForDkg(data: Uint8Array, public_key: DkgPublicKey, conditions: Conditions)
  • ferveo_tdec::api::encrypt(message, aad, public_key, rng):
    • BLS12-381 arithmetic
    • ChaCha20Poly1305 encryption
    • Rust-side serialization
• nucypher_core::AccessControlPolicy
• nucypher_core::ThresholdMessageKit

Decryption (taco/src/tdec.ts/retrieveAndDecrypt()):

• nucypher_core::
  • ThresholdDecryptionRequest
    • .encrypt()
      • EncryptedThresholdDecryptionRequest
        • encrypt_with_shared_secret
          • ChaCha20Poly1305 encryption
  • SessionStaticSecret
    • .new()
      • crate::secret_box::kdf (HKDF)
    • .derive_shared_secret()
      • x25519_dalek::{PublicKey, SharedSecret, StaticSecret}
  • EncryptedThresholdDecryptionRequest
    • encrypt_with_shared_secret
    • decrypt_with_shared_secret
  • ThresholdMessageKit
    • .decryptWithSharedSecret()
      • ferveo::api::decrypt_with_shared_secret
        • SecretBox
        • Chacha20Poly1305
• ferveo::binding_wasm::combine_decryption_shares_simple
  • ferveo::api::combine_shares_simple
    • BLS12-381 arithmetic

After this preliminary analysis, we can see that we currently depend on these external primitives:

• BLS12-381 arithmetic
• ChaCha20Poly1305 encryption
• HKDF
• x25519_dalek
• SecretBox
• Rust-side serialization

A cursory search I can see several 3rd party libraries that can help us with this process, but we need a more in-depth investigation.

• BLS12-381 and x25519 pure TS/JS implementation: https://github.com/paulmillr/noble-curves/blob/94d00668f19ea38a6956cc0afe1051038b764fcb/README.md?plain=1#L46
• ChaCha20Poly1305 implementation: https://github.com/paulmillr/noble-ciphers
• HKDF: https://github.com/panva/hkdf

[derekpierre]

I was thinking about this a bit more.

Is there a wold in which we compile our Rust library for iOS/Android (Mobile), and other non-browser platforms eg. cargo-ndk, cbindgen, etc.? Currently, we produce wasm/python-bindings, but it seems you can also compile for other platforms:

• https://rust-dd.com/post/building-a-rust-native-module-for-react-native-on-ios-and-android
• https://www.youtube.com/watch?v=mErOZcKqR0c
• https://digvijayu.medium.com/building-cross-platform-library-with-rust-for-ios-and-android-c56a448e4804
• https://artificialworlds.net/blog/2022/07/06/building-cross-platform-rust-for-web-android-and-ios-a-minimal-example

Perhaps a drawback here is the potential shim layers that may be needed for the various platforms and maintaining those? Again, I don't know enough about the Rust details and whether or not this is a viable/reasonable comparable option, but perhaps something we can also explore. Maybe we can ping @fjarri to get his initial thoughts.

[fjarri]

I don't really know much about mobile platforms. I think it's possible to compile Rust crate as a library and then use it in an app, but I've never done it myself.

[cygnusv]

Serde serialization in TS: https://www.npmjs.com/package/ts-serde