Comments (5)
@staheri14 @s1fr0 please clarify:
- What hash should be used to hash the signature before feeding it to zerokit as a seed?
- What message would you prefer we use?
- Most ZK projects I have see use eth personal sign. Do we want to also use it? Should we try to use EIP-712 instead? It might have better security if the wallet checks the
name
in the data struct to sign against the domain name of the app - Discussion about a password and nonce were made, do we want to implement either? Feel free to forward me to an RFC if I missed it.
- I assume that the membership id is present in the event logs of the registration transaction, am I correct? @richard-ramos ?
from js-rln.
I assume that the membership id is present in the event logs of the registration transaction, am I correct? @richard-ramos ?
Yes, it's the index
parameter of the event MemberRegistered(uint256 pubkey, uint256 index)
from js-rln.
@fryorcraken for 2 and 4, the contract address and the nonce are definitive. With nonce we allow multiple registrations to the same membership contract. However, for the password, we yet did not get to an agreement. To me still it makes sense to have an app-level password to make sure the same seed (hence rln credentials) will not be derived by a malicious irrelevant application.
from js-rln.
-
Given that entropy comes from a signature (high-entropy) rather than a password (low entropy) I would derive the secret using
HKDF
with SHA256. Note that HKDF can take not only the raw signature as input, but also an optional salt and info input data (which are hashed all together). This feature can be particularly useful to mitigate rainbow table attacks (unlikely here since we don't use passwords) and to pass the nonce to the key derivation function rather than to the signing routine. Since we don't want to store salt, we could just set it to some value derived again from signature. -
I think "Sign this message to derive credentials for app X deployed on contract X with chain-id X" would be enough. To generate multiple credentials, we can pass the nonce (actually better to call it counter, otherwise we should think how to persist a random nonce) to the key derivation function (see 1.). I don't agree with the usage of a password: this credential derivation method employing wallet signatures is done in order to avoid remembering/storing additional credentials beside the wallet auth data. Furthermore if require a password we can derive credentials directly from that with no need for wallet signature. Note however that what I described in 1. still allows you to pass arbitrary data to the key derivation function, including any eventual app-level info/password. If you think is necessary to discuss it further, @staheri14 please open an issue where we can discuss security assumptions for a password approach in a more structured way.
-
Had just a glance to EIP-712 full specification, but yes Sign Typed Data v3/v4 is what I was looking at. Plus chain-id is already there along with other meaningful fields (domain/name) and there is an open message field. I think this format enormously mitigates any potential replay/impersonation attack.
-
See 2.
-
Yes!
from js-rln.
Note that it may be more efficient (less network request) to look at the merkle tree to recover the membership id. See waku-org/nwaku#1278 (comment)
from js-rln.
Related Issues (20)
- Ensure docs are up to date and publish them
- fix(rln): convert id commitments to uint256 from LE on register HOT 6
- Add interop tests with nwaku/go-waku
- Better rationale of repo and diff with existing rlnjs HOT 1
- Track package size to provide valuable insight to developer HOT 4
- Support Import and Export of RLN Credentials HOT 3
- feat: update to latest contract per rfc HOT 1
- Slowness to generate proofs with recent zerokit versions HOT 9
- Persist Merkle tree, valid roots and last sync block HOT 2
- clean nullifier table HOT 2
- Move this to js-waku monorepo
- feat: keystore introp tests with nwaku
- feat: improve tests for RLNContract
- feat: better developer experience HOT 2
- feat: wasm caching
- bug: proof is not verified HOT 4
- js-rln keystore is not compatible with nwaku HOT 2
- feat: use rln-js HOT 1
- feat: js-rln optimizations HOT 3
- bug: proof verification and timestamp problems HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from js-rln.