<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:base="https://nickler.ninja/">
  <title>Category: crypto | nickler&#39;s</title>
  <link href="https://nickler.ninja/categories/crypto/atom.xml" rel="self"/>
  <link href="https://nickler.ninja/"/>
  <updated>2023-07-31T15:17:00+00:00</updated>
  <id>https://jonasnick.github.io/</id>
  <author>
    <name>Jonas Nick</name>
  </author>
  <generator uri="https://www.getzola.org/">Zola</generator>
  <entry>
    <title type="html">Intuition for Zero-Knowledge Proofs</title>
    <link href="https://nickler.ninja/blog/2023/07/31/intuition-for-zero-knowledge-proofs/"/>
    <updated>2023-07-31T15:17:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2023/07/31/intuition-for-zero-knowledge-proofs</id>
    <content type="html">&lt;p&gt;While working on &lt;a rel=&quot;external&quot; href=&quot;https://eprint.iacr.org/2022/510.pdf&quot;&gt;Bulletproofs++&lt;/a&gt; I realized there were gaps in my understanding of zero-knowledge proofs.
I did a quick search through the literature to find proofs for zero-knowledge that can help my understanding.
I found that either the protocols were too different to Bulletproofs(++) or the proofs seemed incomplete.&lt;/p&gt;
&lt;p&gt;For example, in Bulletproofs, removing blinding values from the protocol does not affect the proof.
This would make it seem like the changed protocol is ZK, but upon closer inspection, it isn’t.&lt;/p&gt;
&lt;p&gt;To help developing an intuition for ZK, I created a little demo proof for a toy ZK protocol.
You can find at at&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://github.com/jonasnick/little-crypto-notebook&quot;&gt;https://github.com/jonasnick/little-crypto-notebook&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;The toy protocol is a heavily simplified variant of Bulletproofs range proofs.
In short, it proves that a committed value is the product of two other committed values.&lt;/p&gt;
&lt;p&gt;I hope you find the demo useful too.
My goal is to continue expanding the little crypto notebook if time permits.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">MuSig2: Simple Two-Round Schnorr Multisignatures</title>
    <link href="https://nickler.ninja/blog/2020/11/29/musig2-simple-two-round-schnorr-multisignatures/"/>
    <updated>2020-11-29T23:25:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2020/11/29/musig2-simple-two-round-schnorr-multisignatures</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;/images/2020-musig2.png&quot; width=&quot;560&quot;&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;: Multi-signatures enable a group of signers to produce a single signature on a given message. Recently, Drijvers et al. (S&amp;amp;P’19) showed that all thus far proposed two-round multi-signature schemes in the DL setting (without pairings) are insecure under concurrent sessions, i.e., if a single signer participates in multiple signing sessions concurrently. While Drijvers et al. improve the situation by constructing a secure two-round scheme, saving a round comes with the price of having less compact signatures. In particular, the signatures produced by their scheme are more than twice as large as Schnorr signatures, which arguably are the most natural and compact among all practical DL signatures and are therefore becoming popular in cryptographic applications (e.g., support for Schnorr signature verification has been proposed to be included in Bitcoin). If one needs a multi-signature scheme that can be used as a drop-in replacement for Schnorr signatures, then one is either forced to resort to a three-round scheme such as MuSig (Maxwell et al., DCC 2019) or MSDL-pop (Boneh, Drijvers, and Neven, ASIACRYPT 2018), or to accept that signing sessions are only secure when run sequentially, which may be hard to enforce in practice, e.g., when the same signing key is used by multiple devices.&lt;/p&gt;
&lt;p&gt;In this work, we propose MuSig2, a novel and simple two-round multi-signature scheme variant of the MuSig scheme. Our scheme is the first multi-signature scheme that simultaneously i) is secure under concurrent signing sessions, ii) supports key aggregation, iii) outputs ordinary Schnorr signatures, iv) needs only two communication rounds, and v) has similar signer complexity as regular Schnorr signatures. Furthermore, our scheme is the first multi-signature scheme in the DL setting that supports preprocessing of all but one rounds, effectively enabling a non-interactive signing process, without forgoing security under concurrent sessions. The combination of all these features makes MuSig2 highly practical. We prove the security of MuSig2 under the one-more discrete logarithm (OMDL) assumption in the random oracle model, and the security of a more efficient variant in the combination of the random oracle and algebraic group models.&lt;/p&gt;
&lt;p&gt;Read more on &lt;a rel=&quot;external&quot; href=&quot;https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295&quot;&gt;the Blockstream Blog&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">BIP-{Schnorr,Taproot,Tapscript}</title>
    <link href="https://nickler.ninja/blog/2020/11/29/bip-{schnorr/"/>
    <updated>2020-11-29T22:59:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2020/11/29/bip-{schnorr</id>
    <content type="html">&lt;p&gt;&lt;img src=&quot;/images/2020-taproot.png&quot; width=&quot;800&quot;&gt;&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;BIP-Schnorr Abstract&lt;/strong&gt;: This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve secp256k1.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;BIP-Taproot Abstract&lt;/strong&gt;: This document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;BIP-Tapscript Abstract&lt;/strong&gt;: This document specifies the semantics of the initial scripting system under BIP341 [BIP-Taproot].&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id=&quot;some-highlights&quot;&gt;Some highlights:&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;2018-01-23&lt;/strong&gt;: Taproot idea &lt;a rel=&quot;external&quot; href=&quot;https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html&quot;&gt;is proposed&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2018-04-28&lt;/strong&gt;: Work on BIP-Schnorr and what was known as “BIP-metas” (MErkle branches, TAproot, and Schnorr signatures) begins&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2018-07-06&lt;/strong&gt;: BIP-Schnorr draft &lt;a rel=&quot;external&quot; href=&quot;https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html&quot;&gt;is published&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2018-09-25&lt;/strong&gt;: libsecp256k1 &lt;a rel=&quot;external&quot; href=&quot;https://github.com/bitcoin-core/secp256k1/pull/558&quot;&gt;schnorrsig PR opened&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2019-05-06&lt;/strong&gt;: BIP-Taproot and BIP-Tapscript proposals &lt;a rel=&quot;external&quot; href=&quot;https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html&quot;&gt;are published&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2020-01-21&lt;/strong&gt;: Bitcoin Core &lt;a rel=&quot;external&quot; href=&quot;https://github.com/bitcoin/bitcoin/pull/17977&quot;&gt;taproot PR opened&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2020-09-11&lt;/strong&gt;: libsecp256k1 schnorrsig PR merged&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2020-10-15&lt;/strong&gt;: Bitcoin Core &lt;a rel=&quot;external&quot; href=&quot;https://github.com/bitcoin/bitcoin/pull/19953&quot;&gt;taproot PR merged&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2021-05-01&lt;/strong&gt;: &lt;a rel=&quot;external&quot; href=&quot;https://bitcoincore.org/en/2021/05/01/release-0.21.1/&quot;&gt;Bitcoin Core release&lt;/a&gt; with &lt;a rel=&quot;external&quot; href=&quot;https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment&quot;&gt;“Speedy Trial”&lt;/a&gt; activation parameters&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;2021-06-13 (block 687456)&lt;/strong&gt;: Taproot LOCKED-IN&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Block 709632&lt;/strong&gt;: Taproot activation&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Protip: If you have troubles memorizing BIP numbers (like me), achow101 observed that BIP-Taproot’s number, 341, are the reversed digits of BIP-143. The segwit version 0 transaction digest is defined in BIP-143 and version 1 digest is defined in BIP-341.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">MuSig-DN: Schnorr Multisignatures with Verifiably Deterministic Nonces</title>
    <link href="https://nickler.ninja/blog/2020/11/29/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces/"/>
    <updated>2020-11-29T22:53:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2020/11/29/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces</id>
    <content type="html">&lt;p&gt;&lt;a href=&quot;https://www.youtube.com/watch?v=n19vDaVrwY4&quot;&gt;&lt;img src=&quot;/images/2020-musig-dn.png&quot; width=&quot;560&quot;&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;: MuSig is a multi-signature scheme for Schnorr signatures, which supports key aggregation and is secure in the plain public key model. Standard derandomization techniques for discrete logarithm-based signatures such as RFC 6979, which make the signing procedure immune to catastrophic failures in the randomness generation, are not applicable to multi-signatures as an attacker could trick an honest user into producing two different partial signatures with the same randomness, which would reveal the user’s secret key.&lt;/p&gt;
&lt;p&gt;In this paper, we propose a variant of MuSig in which signers generate their nonce deterministically as a pseudorandom function of the message and all signers’ public keys and prove that they did so by providing a non-interactive zero-knowledge proof to their cosigners. The resulting scheme, which we call MuSig-DN, is the first Schnorr multi-signature scheme with deterministic signing. Therefore its signing protocol is robust against failures in the randomness generation as well as attacks trying to exploit the statefulness of the signing procedure, e.g., virtual machine rewinding attacks. As an additional benefit, a signing session in MuSig-DN requires only two rounds instead of three as required by all previous Schnorr multi-signatures including MuSig. To instantiate our construction, we identify a suitable algebraic pseudorandom function and provide an efficient implementation of this function as an arithmetic circuit. This makes it possible to realize MuSig-DN efficiently using zero-knowledge proof frameworks for arithmetic circuits which support inputs given in Pedersen commitments, e.g., Bulletproofs. We demonstrate the practicality of our technique by implementing it for the secp256k1 elliptic curve used in Bitcoin.&lt;/p&gt;
&lt;p&gt;Read more on &lt;a rel=&quot;external&quot; href=&quot;https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6&quot;&gt;the Blockstream Blog&lt;/a&gt; or watch the &lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=n19vDaVrwY4&quot;&gt;pre-recorded talk&lt;/a&gt; we presented at the CCS 2020 conference.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">X-only Pubkeys and Insecure MuSig Shortcuts</title>
    <link href="https://nickler.ninja/blog/2019/11/19/x-only-pubkeys-and-insecure-musig-shortcuts/"/>
    <updated>2019-11-19T13:35:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2019/11/19/x-only-pubkeys-and-insecure-musig-shortcuts</id>
    <content type="html">&lt;p&gt;There are two posts I recently contributed to &lt;a rel=&quot;external&quot; href=&quot;https://medium.com/blockstream&quot;&gt;Blockstream’s engineering blog&lt;/a&gt; expanding on the talk I gave at &lt;a rel=&quot;external&quot; href=&quot;https://www.thelightningconference.com/&quot;&gt;The Lightning Conference 2019&lt;/a&gt;. Cross-posting them here because they fit the theme of this blog:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7&quot;&gt;Reducing Bitcoin Transaction Sizes with x-only Pubkeys&lt;/a&gt;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;This article is about the recent introduction of so-called x-only pubkeys to the Bitcoin Improvement Proposal &lt;a rel=&quot;external&quot; href=&quot;https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki&quot;&gt;BIP-schnorr&lt;/a&gt; […] significantly reducing the weight of every transaction output without any loss in security. By removing the Y-coordinate byte from compressed public keys currently used in Bitcoin, public keys end up with a 32-byte representation. We are going to look at how it works, why that’s useful, and sketch a security proof.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da&quot;&gt;Insecure Shortcuts in MuSig&lt;/a&gt;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Using BIP-Schnorr-based multisignatures, no matter how many signers are involved, the result is a single public key and a single signature indistinguishable from a regular, single-signer BIP-Schnorr signature. This article is about optimizing implementations of multisignature protocols and why seemingly harmless changes can totally break the security.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;/li&gt;
&lt;/ul&gt;
</content>
  </entry>
  <entry>
    <title type="html">Secure Protocols on BIP-taproot</title>
    <link href="https://nickler.ninja/blog/2019/06/25/secure-protocols-on-bip-taproot/"/>
    <updated>2019-06-25T22:42:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2019/06/25/secure-protocols-on-bip-taproot</id>
    <content type="html">&lt;p&gt;&lt;a href=&quot;https://youtu.be/DKOG0BQMmmg?t=21866&quot;&gt;&lt;img src=&quot;/images/2019-breaking.png&quot; width=&quot;560&quot;&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;At &lt;a rel=&quot;external&quot; href=&quot;https://breaking-bitcoin.com/&quot;&gt;Breaking Bitcoin&lt;/a&gt; 2019 in Amsterdam I gave a talk about how to build secure protocols on BIP-taproot or more specifically how to avoid the dangers we learned about so far.
There was not enough time to cover everything.
The talk also gives an introduction to how to use our &lt;a rel=&quot;external&quot; href=&quot;https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/include/secp256k1_musig.h&quot;&gt;MuSig implementation in libsecp256k1-zkp&lt;/a&gt;.
The video recording is on &lt;a rel=&quot;external&quot; href=&quot;https://youtu.be/DKOG0BQMmmg?t=21866&quot;&gt;youtube&lt;/a&gt; (&lt;a href=&quot;/slides/2019-breaking.pdf&quot;&gt;slides&lt;/a&gt;).
Thanks to &lt;a rel=&quot;external&quot; href=&quot;https://twitter.com/kanzure&quot;&gt;kanzure&lt;/a&gt; there’s also a &lt;a rel=&quot;external&quot; href=&quot;https://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/secure-protocols-bip-taproot/&quot;&gt;transcript&lt;/a&gt; of the talk.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Erratum&lt;/strong&gt;: MuSig nonces can not be pre-shared. Only nonce commitments. See &lt;a rel=&quot;external&quot; href=&quot;https://github.com/ElementsProject/secp256k1-zkp/pull/73&quot;&gt;https://github.com/ElementsProject/secp256k1-zkp/pull/73&lt;/a&gt; for details.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">Schnorr and Taproot in Lightning</title>
    <link href="https://nickler.ninja/blog/2018/09/04/schnorr-and-taproot-in-lightning/"/>
    <updated>2018-09-04T13:24:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2018/09/04/schnorr-and-taproot-in-lightning</id>
    <content type="html">&lt;p&gt;&lt;a href=&quot;https://www.youtube.com/watch?v=QrX1SpD6l9g&amp;feature=youtu.be&amp;t=7524&quot;&gt;&lt;img src=&quot;/images/lightninghackday-youtube.png&quot; width=&quot;560&quot;&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Last weekend a bunch of hackers assembled for the 3rd Lightning Netword Hackday in Berlin.
The event was packed with interesting sessions, neat hacks and exciting discussions which were concluded with the traditional dinner &amp;amp; drinks at ROOM77.
I gave a talk about “Schnorr and Taproot in Lightning” (&lt;a href=&quot;/slides/2018-hackday.pdf&quot;&gt;slides&lt;/a&gt;, &lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=QrX1SpD6l9g&amp;amp;feature=youtu.be&amp;amp;t=7524&quot;&gt;video&lt;/a&gt;) focusing on privacy and security implications.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">Blind Signatures in Scriptless Scripts</title>
    <link href="https://nickler.ninja/blog/2018/07/31/blind-signatures-in-scriptless-scripts/"/>
    <updated>2018-07-31T14:53:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2018/07/31/blind-signatures-in-scriptless-scripts</id>
    <content type="html">&lt;p&gt;&lt;a href=&quot;https://youtu.be/XORDEX-RrAI?t=25484&quot;&gt;&lt;img src=&quot;/images/bob-youtube.png&quot; width=&quot;560&quot;&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;At the recent Building on Bitcoin conference in Lisbon I gave a talk about a few new ideas in the scriptless scripts framework.
The first part was mainly about &lt;a rel=&quot;external&quot; href=&quot;https://github.com/apoelstra/scriptless-scripts/pull/1&quot;&gt;blind coinswaps&lt;/a&gt;, which is a way to swap bitcoins with a tumbler without revealing which coin are swapped.
The second part about how to exchange ecash tokens peer-to-peer using scriptless scripts and Brands credentials.
You can find the talk &lt;a rel=&quot;external&quot; href=&quot;https://youtu.be/XORDEX-RrAI?t=25484&quot;&gt;on youtube&lt;/a&gt; and the slides &lt;a href=&quot;/slides/2018-bob.pdf&quot;&gt;here&lt;/a&gt;.
Thanks to &lt;a rel=&quot;external&quot; href=&quot;https://twitter.com/kanzure&quot;&gt;kanzure&lt;/a&gt; there’s also a &lt;a rel=&quot;external&quot; href=&quot;https://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/blind-signatures-and-scriptless-scripts/&quot;&gt;transcript&lt;/a&gt; of the talk.&lt;/p&gt;
&lt;p&gt;EDIT: I’ve added a note about the security of Blind Schnorr signatures against forgery to the &lt;a href=&quot;/slides/2018-bob.pdf&quot;&gt;slides&lt;/a&gt;.
In short, a naive implementation of the scheme is vulnerable to &lt;a rel=&quot;external&quot; href=&quot;http://www.enseignement.polytechnique.fr/informatique/profs/Francois.Morain/Master1/Crypto/projects/Wagner02.pdf&quot;&gt;Wagner’s attack&lt;/a&gt;.
An attacker can forge a signature using 65536 parallel signing sessions and &lt;code&gt;O(2^32)&lt;/code&gt; work.&lt;/p&gt;
</content>
  </entry>
</feed>
