Score:5

Crypto

How to reveal/prove some personal information later

Maloo

4/6/24, 7:29 PM

I want to put some personal info like name and email in e.g. some program that I release to the public but I don't want anybody be able to retrieve those personal info and only when I want they can verify that.

The first and simplest way is to hash my personal info and put the hash in the project, like:

sha265('[email protected]')

But that is not very secure because of brute-force and guessing attacks...

So I think I can add a secret random string/key to it like this:

sha265('secret key'+'[email protected]')

Then whenever I want to reveal/prove my identity I will reveal both my email and the secret key...

And probably it is better to use HMAC like:

hmac(data, key)

Then another question arises that is in which parameter to put my email and in which parameter to put the secret key? Or probably it is not important with the HMAC function and this specific use?

735

1 + 0

commitments

Score:13

Crypto

poncho

4/6/24, 7:50 PM

Congratulations! You've just reinvented hash based commitments.

The idea of 'publish a disguised value' and later 'reveal the value of that disguised value' is known (in cryptographical circles) as commitments; the fundamental properties are:

It should be infeasible to determine, from the commitment, what it stands for ("hiding")
It should be infeasible to reveal ("open") a commitment to two different values ("binding")

There are a number of commitment schemes known; the simplest are hash based commitments, which work pretty much as you said.

The commitment is binding (with the caveat in the next paragraph) if the hash function is collision resistant; showing that it is hiding is slightly trickier (it can't be shown from any of the standard hash security notions), but if the random value is long enough, it is quite plausible.

The only slightly tricky part is that the committer must not be able to change where the random value and where the value is, for example:

sha256( 'secret key' + '[email protected]' )

sha256( 'secret ke' + '[email protected]' )

This can be done either by agreeing beforehand the length of the 'secret key', or including length values for the components in the secure hash.

Now, the obvious question is "if this method is the simplest, why would someone do anything more complex"? Well, some will complain about the 'plausibility' in the hiding property, and want something more solid. In addition, this works if all you need is a basic commitment scheme; however sometimes there is a need to do a zero knowledge proof of the committed values (e.g. these two commitments commit to the same value) - that's painful for hash based commitments, and much more doable with (say) Pedersen commitments.

+ 4

Maloo

4/6/24, 8:01 PM

thank u. currently i want only the simplest but completely secure method (assuming the randomness of the key is sufficient of course) and don't think about zero knowledge proofs. can using HMAC instead of a simple hash solve the problem with the "committer must not be able to change where the random value and where the value is" automatically?

poncho

4/6/24, 8:04 PM

@Maloo: yes, HMAC would be a fine solution to the 'split between random value and committed value' problem (assuming, of course, that the HMAC used a collision resistant hash function, and you didn't truncate the HMAC output - that way, if you did find two different ways to open the commitment, you can use that to demonstrate a hash collision, and we assume you can't do that)

Maloo

4/6/24, 8:13 PM

when using hmac with this specific purpose does it matter in which parameters (key and data parameters of the hmac function) we put our secret key and our personal data? i ask this because in this specific use case both of these are considered secret and when we want we reveal both of them together... so i am thinking that can putting them in different parameters have any important security implications?

poncho

4/6/24, 8:23 PM

@Maloo: my initial thought would be to make the secret key the 'HMAC key' and the personal data the 'HMACed data'; that's closer to how HMAC was designed to be used. In practice, though, it's not likely to matter...

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to reveal/prove some personal information later

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.