Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Matthews Lab
Search
Search
Appearance
Log in
Personal tools
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Atomic cloud storage
(section)
Page
Discussion
British English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Generating zero-knowledge proofs == Generating zero-knowledge proofs is tedious in practice and we’re not going to write any of the code to do this directly. Instead, we’ll just adapt the code that Snarkfront [16] uses for their test_sha.cpp file [17]. Would you believe it – the code already does exactly what we need – it allows us to validate that a preimage matches a given SHA 256 hash as well as assert custom constraints on the preimage – which then become part of the proving and verification key pair. The way that it does the additional custom constraints is also quite simple: you have a preimage – say the word “test” and you can specify a pattern – lets say eq = t??t. This would work if the preimage really did include a word starting and ending with the letter “t” (plus producing the expected hash of course - the most important part.) <syntaxhighlight lang="shell"># Zero knowledge proof with satisfied constraints (should pass) $ echo "hello" | ./test_sha -b 1 -p BN128 -d f572d396fae9206628714fb2ce00f72e94f2258f -e ??ll -n a?a # Note – the code may need to be modified to accept binary data as hex # strings but that would be trivial for any C++ programmers.</syntaxhighlight> This software can then be used to create a preimage template for the serialized hash. We don’t actually care what the second half of the signature is so that just becomes ''????? …'' in the equal string. What we care about is that the R values in the signatures are duplicates and that this preimage matches the expected SHA 256 hash. There’s no need to even worry about validating the sigs directly because if the farmer uses invalid signatures then the transaction won’t confirm and the renter is only signing the next transaction that has that invalid signature TX2 as the input – so Bitcoin does the ECDSA sig validation for us [18]. And … with that we just created a provably insecure signature scheme and then used it directly in a chain of transactions that indirectly pay someone to reveal their ECDSA private keys by reusing R values in signatures [13]. The process now serves to reconstruct the secrets needed to be exchanged to complete a homomorphic encryption scheme for the download based on ECC addition which we then adapted to use ElGamel type stuff [8] [19] to turn it into a public key crypto scheme. Next up: auditing contracts. <span id="the-audit-contract"></span>
Summary:
Please note that all contributions to Matthews Lab may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Matthews Lab:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)