arkworks security model

[skaunov]

I'm trying to understand security presumptions for the lib, and having a hard time with this... zeroize is used to enable memory cleaning, though I noticed no intention to for constant time in implementations. (Is it even relevant for a prover, btw, given how the operations with a secret packed into other proving operations with a secret of different nature so isolation and measuring might be totally unfeasible).

I was hoping to see a note in README-file on this. Maybe there's a page somewhere to read this, or someone could briefly outline the broad approach to me?

---

I found a relevant part on this. Maybe it should be rewritten and placed on the project description(s)?
https://media24.fireside.fm/file/fireside-images-2024/podcasts/transcripts/6/66a36787-cf18-4f96-ba6b-d00e9f507731/episodes/2/2b81efe4-4f9b-410f-92b2-30707c9741c8/transcript.txt

Robert (33:49):
What kind of experience do you try to create for developers who are working with Arkworks?

Pratyush (33:58):
I guess there's two audiences, right? So the protocol developers, and the constraint and application developers above the SNARK level. So for the protocol developers, I think yeah, our aim is to make it so that you can go from the paper to code without worrying about, "Oh, did I do this step correctly? Or is this step secure?" To basically provide secure defaults that a protocol developer can come in and just use them, while still ensuring security without losing efficiency. So by choosing Arkworks, you might get security, but you don't want to sacrifice performance, and we try to balance both of these aims. At the higher level, at the application developer level, our aim is to make sure that even if you are maybe not a SNARK expert, you can still write constraints systems and then applications on top of those in a way that's, even if you're not cryptographically trained, it should not be like you're spending all of your time, just wondering "Is this secure?" Basically provide you with efficient defaults.

Pratyush (34:55):
And I guess at both levels, we want to provide efficient and secure defaults that folks can use, but obviously you know, what we assume of users is slightly different at each level.

Anna (35:06):
Earlier on in the conversation, you actually defined what groups you were targeting, but can you just repeat what those are? So you sort of mentioned for protocol devs, but would you picture like an application developer using Arkworks directly or are they going to have to go through something to interact with it?

Pratyush (35:25):
Right. So the two audiences that I mentioned earlier were people who are developing cryptographic protocols directly, so maybe, you know, implementing SNARKs or implementing you know, a new signature scheme or some other primitive of the SART. So that's group one, and the other group is people who are not developing cryptographic primitives, but other applications using SNARKs. So for example, if I'm implementing Dark Forest, I might not know what is the exact security property of this SNARK and you know, what kind of efficiency it guarantees me. I just want to write my constraint system and then use that within my — like, people who want to use SNARKs as a tool, not as something interesting in and of themselves. So we target both of these folks, and I guess like your question about, you know, "Can somebody just pick up Arkworks and use it within their application?" That is more relevant to the second group of people, the application developers.