bschmidt1 · HackerTrans

Re: Hashing - The point of one-way encryption is that it can't be decrypted. A plaintext password has 1 job, to be read, not saved - yet you want to encrypt it as if it will be saved, but because it's one-way encrypted now it can't be read. What problem did you solve? You created a problem (that you now need ZKP to solve...)

Anyway, the ZKP concept is not about decrypting hashes at all, but looking at peripheral data to prove something (Alibaba Cave - Victor only knows Peggy knew the password because he had access to some other data - the path she took). "checking length etc." only if those hints are already available to the system in some way. And because of this approach, why would you need the hash? Just don't use passwords at all in the case of ZKP right? Simply rely on the other identifying data that you have access to, that you use anyway. Also - how secure is this loose profiling technique compared to email-backed passwords over HTTPS?

I imagine few product use cases allow for a server to trust all the clients with encryption, while not trusting itself - but there are some use cases like when the server is not the source of truth - file system service, or peer-to-peer stuff like ledgers: If the server's purpose is just to maintain a shared ledger and all the clients in the network are trusted.

But in the case we're talking about, of a service that authenticates clients, you're saying you can't trust the authenticator when that is kinda the point of authentication - they don't trust you, or rather - the server cannot tell for sure that any incoming connection is who they say they are, even if it has "zero knowledge" like their IP address and a face scan (your brother in the same house might pass). The point of a username and password is that you want the server to not trust any connecting clients unless they have this specific data precisely.

So I wouldn't use it for auth.

bschmidt1

2 tahun yang laludiscuss

If I had a penny for every straw man argument. Who said anything about writing plaintext passwords to files - you just made that up?

Also you might not understand web dev 101. Every website including this one that uses HTTPS sends encrypted data, the password you enter in a text input is in plaintext. For the backend - as I said above, the server hashes it and saves the hash, never the plaintext password.

That's how it works - nobody said anything about "log files".

bschmidt1

2 tahun yang laludiscuss

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);

bschmidt1

2 tahun yang laludiscuss

First you described exactly the concept of password hashing, now you're describing something else entirely:

> It doesn't answer arbitrary questions about the data.

Why would you need a "ZKP" to prevent anyone from "asking arbitrary questions" you simply don't build that functionality.

When I create a web server and allow people to login through an endpoint, they can't ask arbitrary questions about user data either - how would that functionality even exist without me writing it? Typically the server doesn't even know passwords. It simply compares a hash - the hash is computed client-side and the server never sees the real password.

Any peripheral user data you want to return is up to you. Identity is not "built in" to conventional programming languages.

Furthermore, none of the ZKP libraries on npm do anything. Most of them are utility libraries with functions like "generateUUID" and "leftPad". The ones from providers like Cloudflare (their least popular stuff) are just private/public key encryption libraries that they call "ZKP".

bschmidt1

2 tahun yang laludiscuss

[flagged]

bschmidt1

2 tahun yang laludiscuss

> 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.

bschmidt1

2 tahun yang laludiscuss

> You can't just provide a hash of the solved board

Wait, why not? You could represent the Sudoku board as matrices, here's an example of one block:

    [

      [9, 5, 7]

      [4, 8, 3]

      [6, 1, 2]

    ]

(same idea for 9x9)

Imagine a "Sudoku Online" where we all have our own private boards, but we have a shared public chat like an online game. Any of us can click "Check Solution" which hashes our Suduku board and sends it to the chat. A message might look like:

    *magicalhippo is checking a hash... f3ghziiv × Failed*

    *bschmidt1 is checking a hash... 242eef7z × Failed*

    *magicalhippo is checking a hash... zzw4zq3x  Passed*

All players see the hash activity in the public chat, but none of us can see each others' boards - we only have insight to whether or not the solution was valid.

The validity check could run on a central trusted server, like where the game is hosted, or in a peer-to-peer setup a condition of passing could be that a peer machine must validate it. So no client can validate their own hash. It could even be in an "Unverified" state until some threshold % of players have validated it - could do anything you want, but I don't see how "ZKPs" offer any solutions.

Most of the libraries are either utils that have like generateUUID functions in them, or they're private/public key libraries that let you wrap functions in an additional encrypted layer. Haven't seen a goto ZKP npm yet or heard anything about what it improves/solves.

bschmidt1

2 tahun yang laludiscuss

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 need "ZKPs" to do this trivial task.

and

> There's no way to check that someone's age is old enough with just a hash

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).

Re: Passport verification

Anybody can verify any document with enough identifying information about the document and a registry to match it up to. You don't need a private/public key library wrapped around any functions to accomplish that, but the government probably requires the photo for a reason. Maybe you can verify the document, but a lot of services are going to require photo identification regardless of what your library can do without a photo. Again trying to find what problem this solves. Would have been way cooler if you said it verified faces with passport photos - that's the hardest part.

bschmidt1

2 tahun yang laludiscuss

> ZK proof can prove anything

Apparently not, isn't it designed specifically such that it's scoped to a particular "proof"?

You guys always say "without it linking you to your identity" as if identity is built into JavaScript or something. How does using a password hash inherently leak my PII? What problem does ZKP solve?

Using conventional development you can also do the trivial stuff you mentioned like running password through regexp.

bschmidt1

2 tahun yang laludiscuss

This is the same fundamental thing as the password hash example. I can verify you without ever seeing your password, the policeman can verify you without ever seeing your documents - same exact concept.

My question is then: What is unique to ZKPs? Are the ZKP folks just asking us to start calling these techniques "ZKPs"?

When I use Clear for IDV is that a ZKP? Just like your example, they show the ID to Clear, but I never see the ID.

bschmidt1

2 tahun yang laludiscuss

I can also enter a password without revealing my identity, how is it fundamentally different?

If I use an authentication provider, am I now "using ZKPs" because I can log people in without knowing who they are?

Or if I use any identity verification provider (example: Clear), am I using ZKPs since my app doesn't actually see your identity? We just get the OK from Clear?

bschmidt1

2 tahun yang laludiscuss

Same thing. In my example the function only knows whether the provided hash equals the one on file. Yours is essentially the same - is the provided DOB < the one on file (presumably, today's date 18 years ago). No other data is known about the person in either case.

This is also accomplished by just properly scoping the function. Considering the widespread availability of solutions to this well-known* problem, I wonder why anyone would "use ZKPs" - and what does that even mean? What npm should I install - and why?

* where my ACME Challenge fans at

comments