Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimplement TXQR in Rust #504

Closed
burdges opened this issue Feb 16, 2021 · 5 comments
Closed

Reimplement TXQR in Rust #504

burdges opened this issue Feb 16, 2021 · 5 comments

Comments

@burdges
Copy link
Contributor

burdges commented Feb 16, 2021

We want an implementation of TXQR in Rust for Parity signer and probably subkey. We'd encourage some public discussion of the exact design features of TXQR, since maybe we'd find some small improvements.

maciejhirsz/uos#7
novasamatech/parity-signer#457
novasamatech/parity-signer#320

@Slesarew
Copy link

Slesarew commented May 7, 2021

Now we have an MWP!

Receiving end

Parity Signer now allows metadata transfer through this PR (if/when it's merged, that is):
novasamatech/parity-signer#743

Front-end and native component interactions are hidden in react-native, logic is in rust. To test, press the menu button in top-right corner, navigate to network settings, select any substrate-based network (for example, westend), scroll down to "manage metadata" button, then select scanner in the middle on the bottom. Begin scanning, you can skip frames, re-focus and have shaky hands.

Transmitting end

Transmitting end generating apng written in Rust:
https://github.com/paritytech/rtxqr

The example transferable metadata is attached. Message format adheres to still not accepted but proposed format:
https://github.com/Slesarew/uos

That is, actual metadata is prefixed with 530080

I'm looking for further suggestions, current plan includes replacing all Signer transactions with raptorq fountains (or at least all multiframe ones) and maybe I should make a separate app to send apks to upgrade things over the airgap - maybe we should develop a general standard for that?

If there is a demand, I could try to write rust-based native scanner component callable from RN, but this will have longer ETA and I'm not sure it is all that needed.

@burdges
Copy link
Contributor Author

burdges commented May 7, 2021

Very cool! Yes, any multi-frame tx should becomes more user friendly using raptorq, although maybe keep an eye out for regressions at small numbers like two frames or whatever.

We bite off larger obligations ala https://github.com/heartsucker/rust-tuf if we start doing upgrades, since a malicious apk might reactivate the wifi or whatever. I'd expect it'd take too long via QR code anyways though. I'd instead think people could use memory cards,

@burdges
Copy link
Contributor Author

burdges commented May 7, 2021

As an aside, we'll try to make some progress on w3f/schnorrkel#11 soon-ish, which should be interesting for parity signer. Feel free to chat with me about it on Element.

@Slesarew
Copy link

I'd instead think people could use memory cards,

This does not really fix malicious apk hazard, but any updates without full phone wipe are hazardous in fact.

The only safe alternative might be with memory cards, but in that case the card should be physically destroyed after update, otherwise this will not be safe. If we follow this path, we'll probably need to post safe memory card destruction protocols so that people don't hurt themselves and at the same time complete the task securely with little effort.

@alxs alxs transferred this issue from w3f/General-Grants-Program Jul 20, 2021
@Noc2
Copy link
Collaborator

Noc2 commented Aug 27, 2024

I'm closing this issue since it has been open for a very long time.

@Noc2 Noc2 closed this as completed Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants