Investigate Zkattest / TOM 256

[andrea-dintino]

Repo ZKP flow ubique:

https://github.com/heidiverse/zkattest-rs

https://github.com/heidiverse/zk-bridge-services/blob/main/zkp-util/tests/device-binding.rs

TOM 256 curve: https://neuromancer.sk/std/other/Tom-256
Paper: https://eprint.iacr.org/2021/1183.pdf

[ms8421ms]

After investigating ZKattest, it turns out that:

• the ZKattest paper (https://eprint.iacr.org/2021/1183.pdf) presents some errors and security misdesigns, as pointed out in https://eprint.iacr.org/2023/1595.pdf (these were acknowledged by ZKattest authors);
• the same paper proposes CDLS, an improved version which however still uses Tom's curves (https://neuromancer.sk/std/other/Tom-256) which are not standard nor well documented;
• it also mentions the possibility of using the Groth-Kohlweiss construction (https://eprint.iacr.org/2014/764.pdf) to implement a ring signature from pre-existing ECDSA keys. In this case, however, the user must have direct access to private keys, and not only to the signing functionality;
• it seems that the state of the art for building proofs of possession for legacy signatures (and thus ring signatures from pre-existing keys which are not directly accessible by users) is https://eprint.iacr.org/2025/538.pdf. For ECDSA, it proposes two approaches: one based again on Tom's curves, and the other using zkSNARK as a side protocol to perform some of the verifications among the commitments.

This suggests we try to use the already implemented Longfellow ZK instead.

[jaromil]

It may be worth a review blog post on our think & do tank feed.