6 ms·

Re: scoped In response to your comment The ZK proof can prove anything, like that the password has enough special symbols and numbers - you definitely do not n

• TimJRobinson 2y ago
  > you definitely do not need "ZKPs" to do this trivial task. You haven't provided an alternative way though? If you're looking for more complicated things they can do see: https://news.ycombinator.com/item?id=41430157 https://news.ycombinator.com/item?id=41430157 > Yeah you can, you log them in then link them to that userData with an identifier - typically an email address or unique user ID. You can easily write the login API to know nothing but hashes, or you can write it to respond with - to use your example that user's age - if the password is correct (without ever actually knowing the password). This doesn't make sense, how do you verify someones age without getting their birthday? Hashes are binary yes/no checks, not range checks. > Anybody can verify any document with enough identifying information about the document and a registry to match it up to. So your alternate solution is that every government in the world runs an API you can check a passport against? Instead of them just providing a known public key they signed the passport with? Sounds way over complicated compared to a ZK proof.
  • bschmidt1 2y ago
    > Re: Validating passwords > You haven't provided an alternative way though? Check if it has numbers: \d Check if it has symbols: \W Check if it's 6-64 chars long: {6,64} > This doesn't make sense Promise you it's how it works. > Hashes are binary yes/no checks Nope, just means encrypted text. > every government in the world runs an API Hilarious you think a decentralized approach where every participant has a copy of an append-only ledger is simpler than a central server with SQL database. The argument for decentralization was never that it was simpler - it's of course way simpler in many ways to have a single source of truth. If you mean using that passport library on a regular server, then you also have to run an API or nobody can use it.
    • TimJRobinson 2y ago
      - Do you not understand that client side checks are insecure? - As you're still not getting it, how about this: This is a sha256 hash of my birthday, write a function that returns if I'm over 21: `1028d7ea22cbbcb17c4926b08b591506227d7b0e32ce6ce76122461e551a5ab2` - Nothing I've mentioned needs an append only log, where are you even getting that from? A ZK proof is created from only the data stored on the passport chip.
      • bschmidt1 2y ago
        [flagged]
        • bschmidt1 2y ago
          To address edits: > when to encrypt It depends on what you want to do, if it's user login over HTTPS you can pass a plaintext password to the server and hash/compare on the server only. It would still be secure because the plaintext is never saved in a db (only the hash is), and was TLS encrypted in transport. ----- > This is a sha256 hash of my birthday, write a function that returns if I'm over 21: `1028d7ea22cbbcb17c4926b08b591506227d7b0e32ce6ce76122461e551a5ab2` You hash the point of access like a password or key, not the data itself. When the access is granted, you return the data. sha256 is never meant to be decrypted. It would be like this: interface User { id: sha256; name: string; age: number; } const users: User[] = fetchUsers(); const isOver21 = plaintextId => users[encrypt(plaintextId)]?.age >= 21; If your requirement is to actually to decrypt the sha256 you misunderstand the purpose of one-way encryption. That said - if you really wanted such a system, for such a finite list of dates (365 x 21 = 7665) you can easily maintain an array of the valid 7,665 sha256's on any given day. If it doesn't match a sha256 on file, that birthdate is not a person over 21. const validHashes: BirthdateHashSha256[] = seedHashesForToday(); const isOver21 = hash => validHashes.includes(hash);