crypto-wasi

crypto-wasi is subset of apis of nodejs's crypto module for wasm32-wasi, implemented in rust, powered by WASI Cryptography APIs.

lib.rs:

crypto-wasi is subset of apis of nodejs's crypto module for wasm32-wasi, implemented in rust, powered by WASI Cryptography APIs. This library is developed and tested over WasmEdge runtime

Note: The api of this library is not completely consistent with the api of nodejs.

Currently Subset Implemented

• [Hash] (sha256, sha512, sha512-256)
• [Hmac] (sha256, sha512)
• [hkdf] (sha256, sha512)
• [pbkdf2] (sha256, sha512)
• scrypt
• [Cipheriv] & [Decipheriv] (aes-128-gcm, aes-256-gcm, chacha20-poly1305)
• [generate_key_pair] (rsa-[2048, 3072, 4096], rsa-pss-[2048, 3072, 4096], ecdsa-[prime256v1, secp256k1, secp384r1], ed25519, x25519)
• KeyObject ([PublicKey] & [PrivateKey])
• [sign] & [verify]
• [diffie_hellman]

Working In Process

• create_public_key & create_private_key
• ECDH (you can use generate_key_pair and diffie_hellman as alternatives)

Not Implemented

• createCipher & createDecipher: This function is semantically insecure for all supported ciphers and fatally flawed for ciphers in counter mode (such as CTR, GCM, or CCM).
• generateKey & createSecretKey: In nodejs, SecretKey is just store the raw key data. In wasi-crypto, SymmetricKey is equivalent to SecretKey, which is also just store the raw key data in WasmEdge's implementation. But in wasi-crypto, each key is required to be bound to a kind of algorithms, which cause some complications when managing keys and reusing keys. So we're not going to implement SecretKey.

Known Issues:

• ECDSA_P384_SHA384 key export as Jwk: elliptic curve routines:ec_GFp_simple_point2oct:buffer too small
• ECDSA_P384_SHA384 in sign & verify use sha256 as digest actually