1

Im working on a project where i want to store encrypted data on-chain and later reveal that data. For this process im thinking of using a trusted off-chain worker to act as a "key-manager". This ocw should be able to generate RSA keypairs, store his public key on-chain and keep the private key in his local storage. A user would use the advertised public key to encrypt his message and store it on-chain. After "n" blocks the offchain worker would reveal that message to everyone.

Im having trouble in finding a substrate compatible crate to handle RSA keypair generation,encryption and decryption. I tried to use pure rust crates such as rsa(https://crates.io/crates/rsa) and ring (https://crates.io/crates/ring) but as soon as i tried to import anything from these crates, substrate panicks.

import panick

I saw that the sc_network pallet is capable of generating rsa keypairs. Is it also capable of encrypting/decrypting? Can i use it outside of runtime safely?

3

3 Answers 3

5

I would also probably advise to avoid rsa. About your issue, it may be possible to import code in runtime by disabling 'std'. In your cargo.toml, import your ring dependency with flag 'no-default-feature' and add needed feature selectively (obviously not 'std'). In no_std environment (runtime), you will not be able to generate key, or any access to rng. Not sure if signing will be possible, but in your use case you probably only need verification (hash commitment on chain, and reveal later by verifying against content).

2

Maybe using the x25519-dalek crate directly and do something along these lines is useful to you?

1
  • 1
    This is precisely what im trying to do, with the exception of using random values to generate the keys (import from file). I tried to import this crate to my ocw pallet and im getting this compile error ( i.imgur.com/dNKpnLn.png ). Commented Mar 19, 2022 at 13:44
1

(Just upgrading my comment so there is an answer.)

It seems that RSA has a reprieve for now: https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not-broken.html

But it is definitely a protocol in need of sunsetting and for new development I would suggest choosing a far stronger alternative.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.