macintosh.world | Log In | Register

Today | News | Books | Recipes
Notes | QuickTake | Wiki | Browse
Maps | Reference | Reddit | YouTube
Chat | Spades | About

Back to HN

AI Meets Cryptography 2: What AI Found in OpenVM's ZkVM

by duha | 98 points | 8 comments | 2026-07-17 09:21:35 Central

Open Source Link | Read Source Here

Open on Hacker News

Comments

SonOfLilit
TL;DR imagine a signature verification library that
verifies a signature indeed signs the given hash, but not
that the signed data hashes to that hash. Woopsie.I guess
nobody's commenting on this because it's very dense math
without any context. Lucky for me I spent an hour or two
yesterday learning how practical non-interactive zero
knowledge proofs work.In SNARKs (and other commitment
schemes based on polynomials in elliptic curve groups,
hope I got the terminology right), you verify the
commitment (unneeded technical details: polynomial on EC
at secret point nobody knows including the committer so he
has to make the polynomial match at most points, and
polynomials that match at most points match at all points)
by multiplying two things you calculated from the circuit
and commitment (which is just a couple of group elements)
and verifying that it comes out as 1. The multiplication
and comparison under encryption is done with a homomorphic
encryption primitive-type thing called a "pairing"
(normally with elliptic curve encryption only addition can
be done on secret group elements that you don't know the
value of).They found a way to tell a specific library that
implements this operation "believe me, this pairing is ok"
that doesn't depend on any of those technical things. Just
"these are not the droids you're looking for". Because it
was not validating that some precomputed thing needed for
the pairing verification actually matches this specific
situation, and there are trivial parameters that would
always yield 1 (but not be valid in the situation).

  > fragmede
Can you say more about the homomorphic encryption bit?
It's fascinating to hear about it being used in
practice and making it out of research.

    > > SonOfLilit
I didn't dive into the technical details of how
pairing works, and in fact leared everything I
know about it from TFA, which went into quite some
detail.

aberoham
What would it mean if someone were to successfully exploit
these? Most or all L2 ecosystems or the magic components
that let them speak to each other would need a hard reset?

  > SonOfLilit
It's a "this transaction is valid even though the
signatures, amounts, potentially everything is wrong
about it" vuln.Every node that uses this library to
validate would lose synchronization with every other
node (if we take them at their word that it's not a
monoculture), the bigger half would be considered
"correct" according to how blockchains work, if it's
the non-exploitable half - just lots of wasted
resources and longer settlement times, if it's the
exploitable half - illegal transactions would need to
be reverted by agreement of the community, which is
some sort of reset.

wren6991
Cryptography *2*? We're still over here trying to
implement Cryptography 1 without side channels, and they
went and invented a new one?

  > aleph_minus_one
This article is part 2 of a series. The first part is>
AI meets Cryptography 1: What AI Found in Cloudflare's
CIRCL> https://blog.zksecurity.xyz/posts/circl-bugs/

    > > SonOfLilit
But to be fair, ZK proofs have strong
"Cryptography 2: the Dark Tower" (2cryp2graphy?)
vibes.The amount and level of power use of
cryptography primitives and their minutiae is
insane. A cryptographic algorithm can usually be
described on a post it note. A non-interactive zk
commitment scheme would take a 200 page
book.(Though to be seriousit's Cryptography 3:
Return of the String, because Cryptography 2 is
Public Key Cryptography)