[TimJRobinson]

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

[flagged]

[bschmidt1]

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

[TimJRobinson]

Lol, well yea if you throw away the zero knowledge part or trust the client to tell the truth of course you don't need zero knowledge proofs. Its not zero knowledge though (you just gave the server the info) and/or isn't proving anything.

This is the situation zero knowledge proofs are used in:

- The client doesn't trust the server and doesn't want to give it any info (that's the zero knowledge part)

- The server doesn't trust the client (that's the proof part)

If you break them of course the problem is much easier to solve.

If the client trusts the server they can give it a scan of their passport.

If the server trusts the client to run that code then you don't need a proof, you may as well just have a popup that says "are you over 21?"

A rainbow table is just breaking the hash and then you may as well not have it, in the real world the client would add a salt so this isn't possible.

[kikimora]

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

:) if I get a penny every time someone logs sensitive information in plain text to some log file without realizing they did.

[bschmidt1]

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