FAQ
Frequently asked questions list
Last updated
Frequently asked questions list
Last updated
zkPass uses Three-Party TLS (3P-TLS), and Hybrid Zero-Knowledge Proof (Hybrid ZK) for secure data handling. It starts with a three-party handshake among a data source (S), user (P), and zkPass node (V), generating shared session keys with Paillier encryption for security. P and V jointly compute keys for encryption and authentication, with V restricted from accessing the user's private data. The process includes standard TLS steps and prepares for zero-knowledge proofs.
zkPass employs a hybrid zero-knowledge approach, merging interactive (VOLE-ZK 23) and non-interactive protocols. VOLE-ZK 23 ensures data origin authenticity and client tamper protection, optimized by SoftSpoken for efficiency and focusing on AND gates for simplicity.
For non-interactive zero-knowledge (NIZK), zkPass uses the SNARK framework. Verified results are signed and added to a Merkle tree in the SBT (Soul Bound Token) contract, ensuring efficient, secure, and private validation.
View the to learn more details.
The truth of HTTPS data relies on two key aspects:
Integrity of Encrypted Data from Trusted Sources: During zkPass's MPC network protocol execution, random nodes are selected to establish a "client" connection with the user, facilitating communication with the server, effectively forming a three-party TLS connection. In this scenario, the user possesses shares of both the encryption key and the MAC key, while the nodes only have the remaining portion of the MAC key. Any attempt by users to tamper with data from a trusted source will result in a failure during MAC verification. Consequently, the integrity of data in the three-party TLS connection is ensured.
Conformance of Data Statements to Verifier Requirements: When assessing the authenticity of data statements, zkPass employs Hybrid ZK technology to safeguard customer privacy. The protocol can only be executed successfully if the data conforms to conditions specified by the template, such as age > 18 or assets < 10000. This ensures that the accuracy and truthfulness of the data are also guaranteed.
To ensure the credibility of data sources, the Prover and Node work together as a client to communicate with the server. Once the Client and Server have completed the SayHello process, the Client will request the server return the certificate. The Node inside the Client can also retrieve the certificate and verify its authenticity to ensure the trustworthiness of the data source.
Prove your private data without uploading any personal privacy details.
Re-designed the standard TLS protocol into a three-party TLS to ensure provenance of private data.
Seamless compatible with any HTTPS websites, no API or license required.
The zkPass protocol guarantees private data's verifiability, authenticity, and validity by utilizing decentralized MPC nodes that verify a user's data integrity before generating a zero-knowledge proof (ZKP). As a result, it becomes impossible for anyone to manipulate or tamper with the data while generating zkSBT.
zkPass's anti-cheating mechanism ensures data integrity and authenticity by using zero-knowledge proofs to verify that client requests and server responses match predefined templates and conditions without accessing or storing private data.
VOLE-based IZK that realizes millisecond-level ZKP generation locally in the browser environment.
The zkPass TransGate operates on the client side and does not retain any private data of the Prover. To access the Server, the Prover utilizes their username and password to log in and acquire an access token. This access token enables the Prover to retrieve information from the server via a public interface. The Prover then employs this information to generate Zero-Knowledge Proofs (ZKP) and submits them for on-chain verification.
Throughout the entire process, the encrypted key remains inaccessible to the Verifier, thereby ensuring the security and confidentiality of the user's private data.
zkPass's anti-cheating mechanism ensures the correctness and integrity of data exchanges between clients and servers through zero-knowledge proofs. The main steps include:
Verifying the Correctness of Client's Request: The client encrypts the request data and ensures that the generated ciphertext matches the expected node ciphertext, preventing tampering.
Validating the Correctness of Client's URL: Ensuring the URL provided by the client matches the predefined template, verifying the correctness of the request address.
Ensuring the Client Receives the Correct Response: Comparing the encrypted response data with the node ciphertext to verify the integrity of the response received by the client.
Matching Response Attributes to the Template: Ensuring that the attributes within the response data align with those specified in the template, verifying the accuracy of the response content.
Validating the Asserted Value’s Correctness: Checking if the value in the response data satisfies certain conditions specified by the template, ensuring the logical correctness of the response data.
Through these steps, zkPass not only guarantees the privacy and security of data verification but also ensures the integrity of client-server communications, preventing malicious tampering and fraudulent activities.
More Details:
zkPass addresses the issue of duplicate accounts with different addresses by selecting a unique and private identification field returned by the server. For instance, for Twitter, the "id" field (displayed as the "reset_id" field in the URL) can be used, and it is hashed before being sent to the blockchain.
To handle different addresses with the same verification account, zkPass employs the overlay mode. For instance, if the hash value is detected to be the same, the current address verification will be marked as "pass," while the previously passed address will be marked as "invalid." This mode can also address the scenario where a user has lost their address.
On the early stage of the protocol development, the Nodes are operated by the zkPass team. As the network expands, there is an incentive for the community to participate and join the network until a dynamic equilibrium is attained.
If the demand for verification rises, the revenue generated by the protocol and the individual nodes, as well as the number of nodes, will increase accordingly. However, as the number of nodes reaches a certain threshold, the income for each node will decrease, leading to a subsequent decrease in the number of nodes.
Ultimately, the network will stabilize and reach a state of equilibrium where the scale of the network is balanced and sustainable.
Each account can only mint the same schema once from a single network. you can simply just mint the same schema in the new address to have the attestation from the previous address voided.
Stay Safe: zkPass TransGate is developed based on Google Manifest V3 framework, introducing stricter permission management to ensure your private data remains secure and inaccessible to any third party, including zkPass.
Stay Safe: Please ensure to install the zkPass TransGate extension from on Google Web Store and use it in a secure network environment. Do not install unofficial tools from unknown sources. Avoid clicking on suspicious links and do not grant permissions to your Web3 wallet without verifying the source.
Feel free to join our to ask more questions.