Question: Is there a reference that gives the design and properties of the ggh_hash function?

[rkshbrv]

I was planning to use ggh_hash as the hash function input to hmac, along with a key and a message; and generate a proof. Is this a feasible approach?

[meilof]

The ggh_hash function is a port from the “knapsack” hash implementation of libsnark, see https://github.com/scipr-lab/libsnark/blob/master/libsnark/gadgetlib1/gadgets/hashes/knapsack/knapsack_gadget.hpp. I think you should be able to use it in a HMAC.

…

On Thu, Sep 9, 2021 at 2:55 PM rkshbrv ***@***.***> wrote: I was planning to use ggh_hash as the hash function input to hmac, along with a key and a message; and generate a proof. Is this a feasible approach? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAJUU3NS7ZTI327N5ZHJ3DUBCVETANCNFSM5DXCKIZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Meilof -- ***@***.***

[rkshbrv]

Thank you @meilof

[rkshbrv]

Hi @meilof I have a couple of followup questions :

• In the libsnark backend you have a function that does key generation, proof generation and verification for @snark functions all in one synchronous function. I would think in a practical deployment these all need to happen 'separately'/independently right? So wondering why you have it this way.
• I have made some changes and used some more methods from python-libsnark to separate these out - I basically made three separate functions and changed the pysnark/runtime to call them based on appropriate new pysnark.runtime variables that need to be set based on which one of keygen, proving or verification you want to do.. I was wondering if you have suggestions with respect to this ?
• Is libsnark the most widely used zk-snark library? I am asking because I gathered from reading something that the ZCash guys now use some Rust library for proofs, although I may be mistaken

[meilof]

In the libsnark backend you have a function that does key generation, proof generation and verification for @snark functions all in one synchronous function. I would think in a practical deployment these all need to happen 'separately'/independently right? So wondering why you have it this way.

The idea is that you can do key generation and proof generation using the same command and this should be easy. The first time you run the program, the key material does not exist yet, so it is generated. The next time you run the program (and it has not changed in the meantime), the key material is re-used. Similarly if you copy the key material from another party who has generated it. So this approach can be used in practical deployments as well. As for verification, with most backends, you can just do verification directly from the backend -- with the exception of libsnark I suppose because it does not have a standalone verification tool.

I have made some changes and used some more methods from python-libsnark to separate these out - I basically made three separate functions and changed the pysnark/runtime to call them based on appropriate new pysnark.runtime variables that need to be set based on which one of keygen, proving or verification you want to do.. I was wondering if you have suggestions with respect to this ?

Interesting! Although I would probably keep the default behaviour as it is, I guess this could indeed be useful. And being able to call verification directly for the libsnark backend would indeed be useful. I suppose for verification, having a separate verification module (python -m pysnark.libsnark.verify or the like) would be nice? For proof generation/verification, I could imagine having separate imports, having to set a function or a global variable -- I don't really have a preference. If you want to share your code you're very welcome :)

Is libsnark the most widely used zk-snark library? I am asking because I gathered from reading something that the ZCash guys now use some Rust library for proofs, although I may be mistaken

I don't really know to be honest... Pysnark does support bellman and bulletproofs backends via zkinderface, they are Rust-based so maybe you mean those?

[rkshbrv]

@meilof thanks for your response. I will certainly share -- right now its not well organized. Will revert. Thanks

[rkshbrv]

The ggh_hash function is a port from the “knapsack” hash implementation of libsnark, see https://github.com/scipr-lab/libsnark/blob/master/libsnark/gadgetlib1/gadgets/hashes/knapsack/knapsack_gadget.hpp. I think you should be able to use it in a HMAC.
…
On Thu, Sep 9, 2021 at 2:55 PM rkshbrv @.> wrote: I was planning to use ggh_hash as the hash function input to hmac, along with a key and a message; and generate a proof. Is this a feasible approach? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAJUU3NS7ZTI327N5ZHJ3DUBCVETANCNFSM5DXCKIZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- Meilof -- @.

Hi @meilof
In an hmac implementation one would need to concatenate the hash output of the "msg + K_ipad" to the "K_opad" and do one more ggh_hash. It doesn't look like this concatenation can be done privately to create a new list of private bits for ggh_hash. Thus it appears that an hmac implementation is infeasible. If possible could you clarify or confirm my understanding? Would appreciate greatly.

[meilof]

Why would it be infeasible? The output of one ggh_hash can be used as the input to another, and you can just concatenate lists of private bits? Op zo 10 okt. 2021 16:49 schreef rkshbrv ***@***.***>:

…

The ggh_hash function is a port from the “knapsack” hash implementation of libsnark, see https://github.com/scipr-lab/libsnark/blob/master/libsnark/gadgetlib1/gadgets/hashes/knapsack/knapsack_gadget.hpp. I think you should be able to use it in a HMAC. … <#m_-7773212664124446794_> On Thu, Sep 9, 2021 at 2:55 PM rkshbrv *@*. *> wrote: I was planning to use ggh_hash as the hash function input to hmac, along with a key and a message; and generate a proof. Is this a feasible approach? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32 <#32>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAJUU3NS7ZTI327N5ZHJ3DUBCVETANCNFSM5DXCKIZQ <https://github.com/notifications/unsubscribe-auth/ACAJUU3NS7ZTI327N5ZHJ3DUBCVETANCNFSM5DXCKIZQ> . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. -- Meilof -- @.* Hi @meilof <https://github.com/meilof> In an hmac implementation one would need to concatenate the hash output of the "msg + K_ipad" to the "K_opad" and do one more ggh_hash. It doesn't look like this concatenation can be done privately to create a new list of private bits for ggh_hash. Thus it appears that an hmac implementation is infeasible. If possible could you clarify or confirm my understanding? Would appreciate greatly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAJUU2VA6ZW7M3UIYRNWRTUGGRYFANCNFSM5DXCKIZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rkshbrv]

Thanks @meilof for your response. I thought so because of a public output corresponding to the first hash output when I tried that. But I now think I was not using an appropriate LinComb method. Will reconfirm. Thanks

[rkshbrv]

@meilof when I was trying to send the bitlength parameter to the LinComb.to_bits() function I was using gghhash.val().bit_length() : I think the invocation of the .val() was causing a public variable to get set on the pb. Currently I have used a fixed 254 value to avoid using the .val() invocation.

[meilof]

That sounds good! Indeed, you cannot use val().bit_length() because that means the number of bits output would depend on the actual hash that is computed. The number of bits should be fixed so that the exact same computation is performed regardless of the input. If you want to have the maximum number of bits of a value, you can use pysnark.runtime.backend.get_modulus().bit_length()

…

On Mon, Oct 11, 2021 at 7:32 AM rkshbrv ***@***.***> wrote: @meilof <https://github.com/meilof> when I was trying to send the bitlength parameter to the LinComb.to_bits() function I was using gghhash.val().bit_length() : I think the invocation of the .val() was causing a public variable to get set on the pb. Currently I have used a fixed 254 value to avoid using the .val() invocation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAJUU6YG64TGL5F5TIYXZ3UGJZFZANCNFSM5DXCKIZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Meilof -- ***@***.***

[rkshbrv]

Thanks @meilof

…

On Mon, 11 Oct 2021 at 22:10, meilof ***@***.***> wrote: That sounds good! Indeed, you cannot use val().bit_length() because that means the number of bits output would depend on the actual hash that is computed. The number of bits should be fixed so that the exact same computation is performed regardless of the input. If you want to have the maximum number of bits of a value, you can use pysnark.runtime.backend.get_modulus().bit_length() On Mon, Oct 11, 2021 at 7:32 AM rkshbrv ***@***.***> wrote: > @meilof <https://github.com/meilof> when I was trying to send the > bitlength parameter to the LinComb.to_bits() function I was using > gghhash.val().bit_length() : I think the invocation of the .val() was > causing a public variable to get set on the pb. Currently I have used a > fixed 254 value to avoid using the .val() invocation. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#32 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/ACAJUU6YG64TGL5F5TIYXZ3UGJZFZANCNFSM5DXCKIZQ > > . > Triage notifications on the go with GitHub Mobile for iOS > < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 > > or Android > < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub >. > > -- Meilof -- ***@***.*** — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR6FSY3P4NQTRF5TWN2ANR3UGMHPPANCNFSM5DXCKIZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.