petal

Sunflowers have math in them, wtf?

2026-10-07T00:00:00.000Z

In the middle of a sunflower, if you look hard enough, you’ll see two families of spirals, one turning clockwise $↻$ and the other counterclockwise $↺$ . Count each one and you usually get two approximate Fibonacci numbers, like 55 or 66. It looks like the plant calculating it, which can seem a bit absurd. It actually isn’t counting anything (duh), it’s just following one dumb rule for the sake of efficiency and the numbers appear on their own.

The dumb rule

A sunflower grows new seeds one at a time at the centre and shoves the older ones outwards. Each new seed goes a fixed angle, say $𝜃$ , around from the previous one. The question is now: which angle packs it best?

Think of $𝜃$ as a fraction of a full turn. If that fraction is a ratio of small integers, say $\frac{1}{4}$ or $\frac{2}{5}$ , the seeds stack into a few straight spokes with ugly gaps between them.

A figure is shown on the site.

Typst source

#import "@preview/cetz:0.5.2": canvas, draw
#let angle = 360deg * 2 / 5  // 2/5 of a turn
#let arms = 5
#let seeds = 150
#let head-radius = 3.5
#let c = head-radius / calc.sqrt(seeds)  // seed n sits at radius c * sqrt(n)
#let seed = c / 2  // dot radius
#let palette = theme.series.slice(0, 3)
#canvas({
  draw.circle((0, 0), radius: head-radius + seed, stroke: (paint: theme.line, dash: "dashed"))
  for n in range(1, seeds + 1) {
    let r = c * calc.sqrt(n)
    draw.circle(
      (r * calc.cos(n * angle), r * calc.sin(n * angle)),
      radius: seed,
      fill: palette.at(calc.rem(calc.rem(n, arms), palette.len())),
      stroke: none,
    )
  }
})

You want the fraction that stays away from lining up for as long as possible, and that’s the golden ratio:

𝜑 = \frac{1 + \sqrt{5}}{2} \approx 1.618

It’s the hardest number to approximate with fractions, because its continued fraction is nothing… but ones.

𝜑 = 1 + \frac{1}{1 + \frac{1}{1 + \frac{1}{1 + ⋱}}}

The golden angle

Turn a full circle by $𝜑^{- 2}$ and you get the golden angle:

𝜃 = \frac{360 °}{𝜑^{2}} \approx 137.508 °

Fibonacci appears because the ratio of consecutive terms of $𝐹_{𝑛 + 1} = 𝐹_{𝑛} + 𝐹_{𝑛 - 1}$ converges to $𝜑$ :

lim_{𝑛 \to \infty} \frac{𝐹_{𝑛 + 1}}{𝐹_{𝑛}} = 𝜑

So the best rational approximations to the golden angle come from Fibonacci numbers, and those are the spiral counts you see in the head.

Placing the seeds

Seed $𝑛$ sits at angle $𝑛 𝜃$ . Its distance from the center grows with the square root of $𝑛$ , keeping the area per seed constant. A disc of radius $𝑟$ has area $𝜋 𝑟^{2}$ , so if each seed takes area $𝐴$ , then $𝑛$ seeds fill

𝜋 𝑟_{𝑛}^{2} = 𝑛 𝐴 \Rightarrow 𝑟_{𝑛} = \sqrt{\frac{𝐴}{𝜋}} \sqrt{𝑛}

With $𝑐 = \sqrt{\frac{𝐴}{𝜋}}$ , the coordinates are:

(𝑥_{𝑛}, 𝑦_{𝑛}) = (𝑐 \sqrt{𝑛} cos (𝑛 𝜃), 𝑐 \sqrt{𝑛} sin (𝑛 𝜃))

A figure is shown on the site.

Typst source

#import "@preview/cetz:0.5.2": canvas, draw
#let phi = (1 + calc.sqrt(5)) / 2
#let angle = 360deg / calc.pow(phi, 2)
#let arms = 21
#let seeds = 400
#let head-radius = 3.4
#let c = head-radius / calc.sqrt(seeds)  // seed n sits at radius c * sqrt(n)
#let seed = c / 2  // dot radius
#let palette = theme.series.slice(0, 3)
#canvas({
  for n in range(1, seeds + 1) {
    let r = c * calc.sqrt(n)
    draw.circle(
      (r * calc.cos(n * angle), r * calc.sin(n * angle)),
      radius: seed,
      fill: palette.at(calc.rem(calc.rem(n, arms), palette.len())),
      stroke: none,
    )
  }
})

A figure is shown on the site.

Typst source

#import "@preview/cetz:0.5.2": canvas, draw
#let phi = (1 + calc.sqrt(5)) / 2
#let angle = 360deg / calc.pow(phi, 2)
#let arms = 34
#let seeds = 400
#let head-radius = 3.4
#let c = head-radius / calc.sqrt(seeds)  // seed n sits at radius c * sqrt(n)
#let seed = c / 2  // dot radius
#let palette = theme.series.slice(0, 3)
#canvas({
  for n in range(1, seeds + 1) {
    let r = c * calc.sqrt(n)
    draw.circle(
      (r * calc.cos(n * angle), r * calc.sin(n * angle)),
      radius: seed,
      fill: palette.at(calc.rem(calc.rem(n, arms), palette.len())),
      stroke: none,
    )
  }
})

That’s pretty much it! If you want to see more, check out this video on the golden ratio by Numberphile :D

CTFs are dead

2026-03-21T00:00:00.000Z

I just came back from Insomni’Hack 2026, it was a great experience, lots of interesting talks! On the last day, from friday evening to saturday morning, the traditional on-site CTF takes place at the SwissTech. It’s generally a very fun event, you meet a lot of people there and the challenges are very well balanced in terms of difficulty.

However, this year’s wasn’t the same. With LLMs becoming better and better at solving these kinds of tasks, CTFs have become a nightmare. Capture the flag competitions are mostly fun because it’s a way to show off your skills, learn new stuff and challenge your ideas against others. People mindlessly using LLMs to solve challenges defeats all three of those points at the same time. Do they even realize?

After wandering in the event and taking glances at everyone’s screen, I would say about 30-40% were just blatantly slop-solving challenges with stuff like codex or claude code. I even heard people being proud of doing this! They were flexing how easy it was to slop-solve the challenges and climb to the top 5 on the scoreboard, even emphasizing themselves that they did not understand a single thing from the solution, but that it still got them their points.

CTFs, as we know them, are dead.

Look, I don’t want to generalize this type of behavior, I know this was an extreme example and that everyone is not as clueless as this guy was. We need to find other ways to assess skill in those fields, or put some serious and efficient restrictions on the usage of LLMs. I’m not saying either that we should be abolishing LLMs completely, they are great tools! But too many people treat them as a complete source of truth and then parade around with points they didn’t earn.

I don’t know what the fix is. Air-gapped rooms? Making people explain their solves on the spot? Honestly, I’m not sure any of that would even work. But something has to change, because right now there’s no point in competing.

LLMs killed my will to do stuff

2026-01-18T00:00:00.000Z

I was 12, in some hotel room in italy, trying to make a discord bot work. My dad helped me smuggle in a raspberry pi and keyboard. I unplugged the tv, booted up the board, followed some random ass tutorial for javascript. The code was a mess, nothing worked right. I spent hours reading error messages I didn’t understand, copying stack overflow answers I understood even less, and ~~painfully~~ slowly making progress. By the end of the weekend, I had something functional. It was a complete catastrophe (each command’s event listener was a separate process), but hey, it was mine!

2026. I’m lying in bed with my laptop, trying to figure out what to build next. Nothing comes to my mind, so I just open mistral and ask for project ideas. I iterate over and over again. Nothing clicks. I give up.

A few days later, I finally find something worth building. I start scaffolding it out by hand, making decent progress. Then I hit a wall: some bug I can’t immediately solve, or a feature that needs research. First instinct? Open the llm, ask it to fix the problem, let it write the solution.

I catch myself doing this even when I know I shouldn’t, even when I know that figuring it out myself is the point. And look, I was always kind of a lazy guy: school never pushed me hard, I could get through with minimal effort, university is the same. I grew up in this “get rewarded for doing barely anything, if not nothing” environment, and it warped how I approach everything, including programming. Long-term effort feels pointless when shortcuts have always worked.

But I don’t think llms created this problem in me, they just made it much worse.

And maybe it’s because they feel like a conversation: it responds, adapts, seems to understand context. It’s really easy to forget you’re talking to statistics and matrix multiplication. Your brain treats it like asking a friend instead of looking something up, feels less like cheating, more like collaboration, even when you know it’s not.

I think my generation is lucky, we learned [to code] before you could just ask an ai to do it. We had to sit with confusion, read documentation (who writes docs anyways?) or articles that didn’t make sense until suddenly it just magically did. We had to earn our understanding through trial and error and frustration. When you can just bypass the struggle entirely, you never build the muscle memory of thinking through problems by yourself.

this is how I feel while writing this but whatever

I see this in myself. I used to be able to sit with a bug/idea for hours, motivated and somewhat focused. Now my attention span has become catastrophic, why bother with something when I can paste it into a chat window and get an answer in seconds?

The fucked up part is that I know this is happening. I can see myself getting worse at the things I care about, yet I still go for the easy solutions anyway. I don’t think the answer is to pretend these tools don’t exist, but I do think we’re not talking/caring enough about what we’re losing. maybe I’m overthinking this, but I kinda miss being stuck on something.

No Ads, No Algorithms, No Problem

2025-03-21T00:00:00.000Z

Back when the Internet was still young (I wasn’t even born), folks would dial up to their favorite BBS (Bulletin Board System) and dive into whatever people were talking about. It was so basic - just pure text posts lined up by date. No flashy ads, no infinite-doomscroll apps. Just people talking to each other.

                    __
                   /  \      r e a l i t y c h e c k B B S
                  /|oo \             san francisco, ca usa
                 (_|  /_)              realitycheckbbs.org
                 _`@/_ \     _              via telnet/web
                |     | \    \\
                | (*) |  \    ))
                |__U__| /  \ //          fidonet 1:218/700
    ______        _//|| _\   /           region 10 mailhub
   / fido \      (_/(_|(____/        california/nevada usa
  (________)          (jm)

They had cool ASCII arts too

Then, as everyone’s grandmother started getting online, the Internet turned into this crazy fight for eyeballs. Companies began watching everything you clicked, trying to get inside your head. Suddenly, you’re drowning in ads, getting pushed toward certain articles, and your feed’s all shuffled around just to keep you glued to your screen.

Today’s Internet feels like walking into a library where librarians follow you around, constantly swapping books on the shelves based on which covers you glance at longest. Look at a cookbook for too long, and suddenly the poetry section is full of food-themed sonnets. Want to read a novel? Too bad, you’re getting a comic book today. It’s like the whole place is trying to sell you something, and it’s exhausting.

Return to Roots

A quite funny thing happened, though. People started realizing. Realizing that their addiction to these never-ending streams of content was making them miserable.

That’s when some Internet old-timers started whispering about something that had been there all along: RSS. Really Simple Syndication. A technology from the early 2000s that never actually died, just got buried under mountains of algorithmic feeds and walled gardens. RSS is beautifully simple. You choose what websites you want to follow, and their latest posts come to you in chronological order. You very own (free) newspaper, curated by you.

It typically looks like this:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
    <channel>
        <title>RSS Title</title>
        <description>This is an example of an RSS feed</description>
        <link>http://www.example.com/main.html</link>
        <copyright>2020 Example.com All rights reserved</copyright>
        <lastBuildDate>Mon, 6 Sep 2010 00:01:00 +0000</lastBuildDate>
        <pubDate>Sun, 6 Sep 2009 16:20:00 +0000</pubDate>
        <ttl>1800</ttl>

        <item>
            <title>Example entry</title>
            <description>An interesting description.</description>
            <link>http://www.example.com/blog/post/1</link>
            <pubDate>Sun, 6 Sep 2009 16:20:00 +0000</pubDate>
        </item>
    </channel>
</rss>

How to Use RSS

As a Reader

Find an RSS Reader: There are many out there, but some popular ones are NetNewsWire, Glance, Folo or miniflux (my favorite)
Subscribe to Websites: Sometimes this is as easy as pasting the website’s URL into your reader. Other times, you might need to look for an icon like this: or try your luck with /(feed|rss|atom)(\.xml)? at the end of the URL.

For websites/content sources that don’t have an RSS feed (e.g. Telegram channels), you can use a bridge service like RSSHub to generate one.
Enjoy: At the beginning, you may find it a bit underwhelming to have a feed with just a few posts. But as you add more and more sources, you’ll have a personalized feed that’s just right for you.

As a Publisher

Most static site generators already support RSS feed generation. Very often, it’s just a matter of enabling it in the configuration file or installing a package. Here’s a list of some popular static site generators and their documentation on RSS feed generation:

Static Site Generator	Documentation	Enabled by Default
Hugo	gohugo.io	Yes
Jekyll	jekyllrb.com	No
Zola	getzola.org	No
Pelican	docs.getpelican.com	Yes (Atom)
Gatsby	gatsbyjs.com	No
Astro	docs.astro.build	No
Eleventy	11ty.dev	No

If your static site generator doesn’t support RSS feed generation, get your hands dirty and write a script to do it! It’s not that hard, and you’ll learn a lot in the process :^)

Atom ? RSS ?

You might have heard of Atom feeds as well. Atom is another XML-based web feed format that’s quite similar to RSS. Atom was created in 2005 as an alternative to RSS, and it’s a bit more modern and extensible. But in practice, the two formats are pretty much interchangeable. Most feed readers can handle both, pick one and stick with it, you’ll be fine. (no harm in supporting both though)

Start using it!!!

If that’s the kind of web you want to exist, start using it. Start sharing it. And maybe, just maybe, we can make it happen.

SquarePants Sponge Hashing

2025-01-06T00:00:00.000Z

In 2007, the NIST (National Institue of Standards and Technology) announced a Cryptographic Hash Algorithm Competition, with the winner being awarded the grant to be standardized as the new SHA-3. It ended in 2012 with KECCAK being announced as the winner.

The function uses a sponge construction, but what the hell is even this thing? Let’s take a look!

We have a message $𝑀$ as our input and the final hash $𝐻$ . We then have two “registers”: $𝑟$ and $𝑐$ , which both make up our state $𝑠$ . These two are initialized with $0$ s in them.

The message $𝑀$ is first padded so that it can fit in exactly $𝑘 \in ℕ$ parts $𝑚_{𝑖}$ , each of size $𝑟$ . The process of “absorption” is the following:

XOR (denoted $\oplus$ ) the message-part $𝑚_{𝑖}$ with the register $𝑟$ bit-by-bit
Scramble the whole register $𝑠$ ( $𝑟$ and $𝑐$ ) altogether to produce a new state $𝑠^{'}$ by applying $𝑓$ The function $𝑓$ needs to generate a pseudo-random permutation of the bits in $𝑠$

A figure is shown on the site.
Pass on the state to the next iteration

We can now “squeeze” our sponge to extract the hash from it, by applying $𝑓$ again and taking a small chunk $ℎ_{𝑖}$ ( $𝑟$ bits) over and over until we have enough for our desired output length.

This whole process can be described with the following diagram:

A figure is shown on the site.

This whole process can also be modified to fit streaming needs, by combining both absorption and squeezing steps at each iteration.

A figure is shown on the site.

Adaptor Signatures FtW

2024-12-03T00:00:00.000Z

[!NOTE] I am not a cryptographer, nor a mathematician. This article is the result of my own research and understanding of the subject. If you find any mistakes, please let me know!

The vast majority of what is written here is taken from various sources, which are listed at the end of this article. I highly recommend you to read them if you want to dive deeper into the subject.

When we compute and share a Schnorr signature, anyone can directly verify if it is valid for the attached message and signer. But what if we wanted to defer revealing the full signature while already emitting it to other people? We can produce such a signature by encrypting the nonce it contains with an additional scalar $𝑦$ .

This scalar will be published “along” with the signature in its public form $𝑌 = 𝑦 \cdot 𝐺$ . The basic signing process is the following:

Sample the random nonce $\hat{𝑟} \leftarrow 𝔽_{𝑞}$ , along with the locking scalar $𝑦 \leftarrow 𝔽_{𝑞}$
Compute their public versions $\hat{𝑅} = \hat{𝑟} \cdot 𝐺$ and $𝑌 = 𝑦 \cdot 𝐺$
Compute the aggregated public nonce $𝑅 = \hat{𝑅} + 𝑌$ .
Hash the challenge $𝑒 = 𝐻 (𝑅 ‖ 𝑃 ‖ 𝑚)$ using the aggregated nonce $𝑅$ and $𝑃 = 𝑝 \cdot 𝐺$ , where $𝑝$ is the private key of the signer.
Compute and publish the (encrypted) locked signature $\hat{𝑠} = \hat{𝑟} + 𝑒 𝑝$

[!NOTE] You may notice that we’re never actually using $𝑦$ in the signing process. This is a feature, not a bug! We can also generate this locked signature only knowing $𝑌$ .

The final published data should be $(𝑅, \hat{𝑠}, 𝑌)$ (along with the message $𝑚$ of course).

Anyone with $𝑦$ will now be able to get the “decrypted” signature $𝑠$ , which is behind the locking point $𝑌$ .

With $𝑟 = \hat{𝑟} + 𝑦$ , we will define $𝑠$ as follows:

\begin{aligned} 𝑠 & = 𝑟 + 𝑒 𝑝 \\ = (\hat{𝑟} + 𝑦) + 𝑒 𝑝 \\ = (\hat{𝑟} + 𝑒 𝑝) + 𝑦 \\ = \hat{𝑠} + 𝑦 \end{aligned}

Likewise, if someone had both $𝑠$ and $\hat{𝑠}$ , they would also be able to recover $𝑦$ :

\begin{aligned} 𝑠 = \hat{𝑠} + 𝑦 \\ ⟺ & 𝑦 = 𝑠 - \hat{𝑠} \end{aligned}

While $\hat{𝑠}$ isn’t a valid Schnorr signature by itself:

\begin{matrix} 𝑒 = 𝐻 (𝑅 ‖ 𝑃 ‖ 𝑚) \end{matrix}

\begin{aligned} \hat{𝑠} \cdot 𝐺 & \overset{?}{=} 𝑅 + 𝑒 𝑃 \\ = (\hat{𝑅} + 𝑌) + 𝑒 𝑃 \\ = (\hat{𝑟} + 𝑦) \cdot 𝐺 + 𝑒 𝑝 \cdot 𝐺 \\ = (\hat{𝑟} + 𝑦 + 𝑒 𝑝) \cdot 𝐺 \\ = (\hat{𝑟} + 𝑒 𝑝) \cdot 𝐺 + 𝑌 \\ = \hat{𝑠} \cdot 𝐺 + 𝑌 \neq \hat{𝑠} \cdot 𝐺 \end{aligned}

We notice we can make the verification equation work if we add the public locking point $𝑌$ :

\hat{𝑠} \cdot 𝐺 + 𝑌 \overset{?}{=} 𝑅 + 𝑒 𝑃

While this doesn’t give us $𝑠$ , we can confirm that by adding $𝑦$ to $\hat{𝑠}$ , the resulting signature will be the one we’re expecting!

\begin{aligned} (\hat{𝑠} + 𝑦) \cdot 𝐺 & \overset{?}{=} 𝑅 + 𝑒 𝑃 \\ = (𝑅 + 𝑌) + 𝑒 𝑃 \\ = (𝑟 + 𝑦) \cdot 𝐺 + 𝑒 𝑝 \cdot 𝐺 \\ = ((𝑟 + 𝑒 𝑝) + 𝑦) \cdot 𝐺 \\ = (\hat{𝑠} + 𝑦) \cdot 𝐺 ✓ \end{aligned}

Atomic Swaps

Exchanging cryptocurrencies between different blockchains is hard. Typically, you’d need a trusted third party to act as a middleman, which would obviously need to be compensated financially for his work. Doing things this way is costly and pretty inefficient. Instead, we can leverage Adaptor Signatures to ensure that either both parties get what they expected, either both get nothing.

We have Alice, holder of $1 ♣︎$ , and Bob, holder of $1 ♥︎$ . They want to exchange both their balances, and we assume they already know each other’s addresses on both chains.

Alice starts by sampling ${\hat{𝑟}}_{𝐴}, 𝑦 \leftarrow 𝔽_{𝑞}$ , and computes an adaptor signature as usual, on a message $𝑚$ that attests the transaction of her $1 ♣︎$ to Bob’s address:

\begin{matrix} {\hat{𝑅}}_{𝐴} = {\hat{𝑟}}_{𝐴} \cdot 𝐺, 𝑌 = 𝑦 \cdot 𝐺 \\ 𝑅_{𝐴} = {\hat{𝑅}}_{𝐴} + 𝑌 \\ 𝑒_{𝐴} = 𝐻 (𝑅_{𝐴} ‖ 𝑃_{𝐴} ‖ 𝑚) \\ {\hat{𝑠}}_{𝐴} = {\hat{𝑟}}_{𝐴} + 𝑒_{𝐴} 𝑝_{𝐴} \end{matrix}

The BIP340 standard expects to receive a signature pair in the form $(𝑂, 𝜎)$ , on which the following check is performed:

𝜎 \cdot 𝐺 \overset{?}{=} 𝑂 + 𝐻 (𝑂 ‖ 𝑃 ‖ 𝑚) 𝑃

If Bob was to try to give in $𝑂 = {\hat{𝑅}}_{𝐴}$ and $𝜎 = {\hat{𝑠}}_{𝐴}$ :

\begin{aligned} {\hat{𝑠}}_{𝐴} \cdot 𝐺 & \overset{?}{=} {\hat{𝑅}}_{𝐴} + 𝐻 ({\hat{𝑅}}_{𝐴} ‖ 𝑃_{𝐴} ‖ 𝑚) 𝑃_{𝐴} \\ \neq \underset{{\hat{𝑠}}_{𝐴} \cdot 𝐺}{\underset{⏟}{{\hat{𝑅}}_{𝐴} + 𝐻 (𝑅_{𝐴} ‖ 𝑃_{𝐴} ‖ 𝑚) 𝑃_{𝐴}}} \end{aligned}

Or $𝑂 = 𝑅_{𝐴}$ and $𝜎 = {\hat{𝑠}}_{𝐴}$ :

\begin{aligned} {\hat{𝑠}}_{𝐴} \cdot 𝐺 & \overset{?}{=} 𝑅_{𝐴} + 𝐻 (𝑅_{𝐴} ‖ 𝑃_{𝐴} ‖ 𝑚) 𝑃_{𝐴} \\ \neq \underset{{\hat{𝑠}}_{𝐴} \cdot 𝐺}{\underset{⏟}{{\hat{𝑅}}_{𝐴} + 𝐻 (𝑅_{𝐴} ‖ 𝑃_{𝐴} ‖ 𝑚) 𝑃_{𝐴}}} \end{aligned}

You could say that he cannot satisfy both the challenge $𝑒$ and the nonce $𝑂$ . To do so, he needs to know $𝑦$ to compute $𝑠_{𝐴} = {\hat{𝑠}}_{𝐴} + 𝑦$ so that when he gives in $𝑂 = 𝑅_{𝐴}$ and $𝜎 = 𝑠_{𝐴}$ :

\begin{aligned} ({\hat{𝑠}}_{𝐴} + 𝑦) \cdot 𝐺 & \overset{?}{=} 𝑅_{𝐴} + 𝐻 (𝑅_{𝐴} ‖ 𝑃_{𝐴} ‖ 𝑚) 𝑃_{𝐴} \\ = (𝑟_{𝐴} + 𝑒_{𝐴} 𝑝_{𝐴}) \cdot 𝐺 \\ = 𝑠_{𝐴} \cdot 𝐺 ✓ \end{aligned}

Back to our stuff, when Bob receives the adaptor signature $(𝑅, \hat{𝑠}, 𝑌)$ from Alice, after having carefully verified that the given data is correct, he can also generate his own adaptor signature $𝑠_{𝐵}$ on Alice’s $𝑦$ by using $𝑌$ :

\begin{matrix} {\hat{𝑟}}_{𝐵} \leftarrow 𝔽_{𝑞} \\ 𝑅_{𝐵} = {\hat{𝑟}}_{𝐵} \cdot 𝐺 + 𝑌 \\ {\hat{𝑠}}_{𝐵} = {\hat{𝑟}}_{𝐵} + 𝐻 (𝑅_{𝐵} ‖ 𝑃_{𝐵} ‖ 𝑚) 𝑝_{𝐵} \end{matrix}

After he sends it to Alice, she can claim the transaction linked to the signature ${\hat{𝑠}}_{𝐵}$ by unlocking it with her $𝑦$ and publishing it to the blockchain. By doing so, everyone will be able to see the transaction and the associated decrypted signature $𝑠_{𝐵} = {\hat{𝑠}}_{𝐵} + 𝑦$ .

After this publication, Bob will also be able to compute $𝑦$ and unlock Alice’s ${\hat{𝑠}}_{𝐴}$ :

\begin{matrix} 𝑦 = 𝑠_{𝐵} - {\hat{𝑠}}_{𝐵} \\ 𝑠_{𝐴} = {\hat{𝑠}}_{𝐴} + 𝑦 \end{matrix}

Nullifying Adaptor Signatures

In the previous case, we saw how two parties could jointly sign a transaction without the need for a trusted third party. But what if one of the parties wanted to cancel the transaction?

If Alice wants to cancel the transaction, she can simply discard her $𝑦$ and never publish it. Bob will then be unable to unlock the signature ${\hat{𝑠}}_{𝐴}$ and claim the transaction.

However, if Bob wants to cancel the transaction, how can Alice confirm that she will never publish $𝑠_{𝐵}$ ? There needs to be some sort of threat against Alice to ensure that she will not publish $𝑠_{𝐵}$ .

Private Key Exposure Threat

By publishing her random nonce ${\hat{𝑟}}_{𝐴}$ , Alice guarantees that she will never publish $𝑠_{𝐵}$ . Otherwise, Bob will be able to recover $𝑦 = 𝑠_{𝐵} - {\hat{𝑠}}_{𝐵}$ and thus compute Alice’s private key $𝑝_{𝐴}$ :

\begin{aligned} 𝑠_{𝐴} & = {\hat{𝑠}}_{𝐴} + 𝑦 \\ = \underset{known}{\underset{⏟}{{\hat{𝑟}}_{𝐴} + 𝑦 + 𝑒}} \cdot 𝑝_{𝐴} \\ ⟺ 𝑝_{𝐴} & = 𝑒^{- 1} (𝑠_{𝐴} - (\hat{𝑟} + 𝑦)) \end{aligned}

Bob can also verify that the nonce ${\hat{𝑟}}_{𝐴}$ published by Alice is authentic:

𝑅_{𝐴} = {\hat{𝑟}}_{𝐴} \cdot 𝐺 + 𝑌

One cool feature of $𝑘$ -of- $𝑛$ treshold schemes, such as Shamir’s Secret Sharing, is that they can be integrated into pretty much anything that has a secret in it. This includes Adaptor signatures locking scalars!

By defining our polynomial $𝑓 (𝑥)$ as follows:

𝑓 (𝑥) = 𝑦 + 𝑎_{1} 𝑥 + 𝑎_{2} 𝑥^{2} + \dots + 𝑎_{𝑘 - 1} 𝑥^{𝑘 - 1}

We can split our locking scalar $𝑦$ into $𝑛$ shares $𝑦_{𝑖} | 1 \leq 𝑖 \leq 𝑛$ :

𝑦_{𝑖} = 𝑓 (𝑖)

With $𝑘$ shareholders forming the recovery group $𝑅$ , we can then collectively reconstruct $𝑦$ with Lagrange interpolation (or any other similar interpolation method):

𝑦 = 𝑓 (0) = \sum_{𝑖 \in 𝑅} 𝑦_{𝑖} \cdot \prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{0 - 𝑗}{𝑖 - 𝑗}

And unlock the adaptor signature!

𝑠 = \hat{𝑠} + 𝑦

References and Suggested readings

The Riddles of Adaptor Signatures
conduition.io
Bitcoin Optech - Adaptor Signatures
bitcoinops.org
Adaptor Signatures: New Security Definition and A Generic Construction for NP Relations⋆
Xiangyu Liu, Ioannis Tzannetos, and Vassilis Zikas
eprint.iacr.org [PDF]

Elliptic Curves for Sane People

2024-11-29T00:00:00.000Z

[!NOTE] I am not a cryptographer, nor a mathematician. This article is the result of my own research and understanding of the subject. If you find any mistakes, please let me know!

The vast majority of what is written here is taken from various sources, which are listed at the end of this article. I highly recommend you to read them if you want to dive deeper into the subject.

Elliptic curve cryptography (ECC) is a fascinating field of study that has been around for a while. It’s a cornerstone of modern cryptography, and it’s used in many applications, from secure messaging to cryptocurrencies. RSA, the most widely used public-key cryptosystem, is slowly being replaced by ECC due to its efficiency and security.

The trapdoor function (easy to do one way, hard the other) for an elliptic curve is the multiplication of a point $𝑃$ by a scalar $𝑛$ which is just adding the point $𝑃$ to itself $𝑛$ times. This operation is denoted as $𝑛 \cdot 𝑃$ . If $𝑛$ is large enough, it is computationally impossible to find $𝑛$ for $𝑄 = 𝑛 \cdot 𝑃$ , being given both $𝑄$ and $𝑃$ , in a reasonable time.

What is a "reasonable time"?

Let’s suppose we have supercomputer that is able to compute $10^{12}$ point multiplications per second (generous assumption).

In a year, we have about $365 * 24 * 60 * 60 ≃ 31^{'} 556^{'} 952$ seconds, that means we could compute:

31^{'} 556^{'} 952 \cdot 10^{12} ≃ 10^{19} [keys/year]

Let’s take a SECP256k1 private key for our example. The elliptic curve is over a 256-bit field, which means we have $2^{256} ≃ 10^{77}$ possible keys.

\frac{10^{77}}{10^{19}} = 10^{77 - 19} = 10^{58} [years]

For reference, the age of the universe is about $10^{10}$ years :D

Even with a quantum computer capable of running non-stop, using Shor’s algorithm, you’d need to perform $\sqrt{2^{256}} = 2^{128} ≃ 10^{38}$ multiplications:

\frac{10^{38}}{10^{19}} = 10^{19} [years]

Let’s start out by graphically representing the addition of two points $𝐺$ and $𝐴$ in an elliptic curve.

One easy way to think of the addition is to draw a line that goes through $𝐺$ and $𝐴$ , and find the third point of intersection with the curve. The symmetrical point is the result of the addition of $𝐺$ and $𝐴$ . This is because elliptic curve have the property that any line between two points intersects the curve at most one more time.

In the case where there is no third point of intersection (i.e. the line is vertical), we define the result of the addition as the point at infinity, denoted as $𝒪︀$ .

A figure is shown on the site.

The resulting point $𝐵 = 𝐺 + 𝐴$ is then reflected to $𝐶$ over the x-axis. This symmetry property is easily explained by the fact that the curve’s $𝑦$ coordinates are squared, so for a given $𝑥$ coordinate, there are two possible $𝑦$ coordinates, $𝑦$ and $- 𝑦$ .

The operation can then be done over and over again to find subsequent points.

A figure is shown on the site.

[!NOTE] We will be working with Short Weierstrass form curves, which are the most common form of elliptic curves used in cryptography. The equation of the curve is $𝑦^{2} = 𝑥^{3} + 𝑎 𝑥 + 𝑏$ .

Given two points $𝐴 (𝑥_{𝐴}, 𝑦_{𝐴})$ and $𝐵 (𝑥_{𝐵}, 𝑦_{𝐵})$ , the resulting coordinates of the point $𝐶 (𝑥_{𝐶}, 𝑦_{𝐶}) = 𝐴 + 𝐵$ can be found by:

Finding the slope $𝑚$ of the line between $𝐴$ and $𝐵$ .
$𝑚 = \frac{𝑦_{𝐵} - 𝑦_{𝐴}}{𝑥_{𝐵} - 𝑥_{𝐴}}$
Finding the $𝑥$ coordinate of $𝐶$ by substituting $𝑦 = 𝑚 (𝑥 - 𝑥_{𝐴}) + 𝑦_{𝐴}$ into the curve equation.
$\begin{matrix} 𝑦^{2} = 𝑥^{3} + 7 \\ ⟺ {(𝑚 (𝑥 - 𝑥_{𝐴}) + 𝑦_{𝐴})}^{2} = 𝑥^{3} + 7 \\ ⟺ (𝑚^{2} {(𝑥 - 𝑥_{𝐴})}^{2} + 2 𝑚 (𝑥 - 𝑥_{𝐴}) 𝑦_{𝐴} + 𝑦_{𝐴}^{2}) = 𝑥^{3} + 7 \\ ⟺ 𝑚^{2} 𝑥^{2} - 𝑚^{2} 2 𝑥_{𝐴} 𝑥 + 𝑚^{2} 𝑥_{𝐴}^{2} + 2 𝑚 𝑦_{𝐴} 𝑥 + 2 𝑚 𝑦_{𝐴} 𝑥_{𝐴} + 𝑦_{𝐴}^{2} = 𝑥^{3} + 7 \end{matrix}$
Grouping each power of $𝑥$ together nicely:
$𝑥^{3} - 𝑚^{2} 𝑥^{2} + (2 𝑚^{2} 𝑥_{𝐴} - 2 𝑚 𝑦_{𝐴}) 𝑥 + (7 - 𝑚^{2} 𝑥_{𝐴}^{2} - 𝑦_{𝐴}^{2} - 2 𝑚 𝑦_{𝐴} 𝑥_{𝐴}) = 0$
We have an single-variable third degree equation, and our good old friend Viète tells us that for a polynomial $𝑃 (𝑥) = 𝑎_{0} + 𝑎_{1} 𝑥 + \dots + 𝑎_{𝑛} 𝑥^{𝑛}$ of degree $𝑛$ , we have $𝑛$ roots:
$𝑃 (𝑥) = 0 ⟺ {\begin{cases} 𝑥 = 𝑥_{1} \\ 𝑥 = 𝑥_{2} \\ \dots \\ 𝑥 = 𝑥_{𝑛} \end{cases}$
Among other properties, these roots $𝑥_{𝑖}$ always satisfy:
$\sum_{𝑖 = 0}^{𝑛} 𝑥_{𝑖} = 𝑥_{1} + 𝑥_{2} + \dots + 𝑥_{𝑛} = - \frac{𝑎_{𝑛 - 1}}{𝑎_{𝑛}}$
Which means that in our case, we can write:
$𝑥_{𝐴} + 𝑥_{𝐵} + 𝑥_{𝐶} = - \frac{- 𝑚^{2}}{1} = 𝑚^{2}$
Because we already know that the line will intersect with $𝐴$ and $𝐵$ (the grouped equation will be satisfied at both $𝑥_{𝐴}$ and $𝑥_{𝐵}$ ), we are left with only $𝑥_{𝐶}$ :
$𝑥_{𝐶} = 𝑚^{2} - 𝑥_{𝐴} - 𝑥_{𝐵}$
Finding $𝑦_{𝐶}$ is as easy as plugging our freshly found $𝑥_{𝐶}$ into the equation of the line and reflecting it over the $𝑥$ -axis:
$𝑦_{𝐶}^{'} = 𝑚 (𝑥_{𝐶} - 𝑥_{𝐴}) + 𝑦_{𝐴}$
$𝑦_{𝐶}^{'}$ is our intermediate point before it being reflected.
$\begin{aligned} 𝑦_{𝐶} = - 𝑦_{𝐶}^{'} & = - 𝑚 (𝑥_{𝐶} - 𝑥_{𝐴}) - 𝑦_{𝐴} \\ = 𝑚 (𝑥_{𝐴} - 𝑥_{𝐶}) - 𝑦_{𝐴} \end{aligned}$

In the case where $𝐺 = 𝐴$ , we can’t really draw a line between the two points, so we take the tangent to the curve at $𝐺$ and find the third point of intersection. This is the result of the addition of $𝐺$ with itself, denoted as $2 \cdot 𝐺$ .

A figure is shown on the site.

To find the tangent at $𝐺 (𝑥_{𝐺}, 𝑦_{𝐺})$ , we need to find the slope $𝑚 = \frac{𝑑 𝑦}{𝑑 𝑥} = 𝑦^{'} (𝑥)$ .

Differentiating both sides with respect to $𝑥$ , $𝑦^{2}$ , which actually depends on $𝑥$ can be written as ${𝑦 (𝑥)}^{2}$ for clarity:

{({𝑦 (𝑥)}^{2})}^{'} = 2 𝑦 (𝑥) \cdot 𝑦^{'} (𝑥)

See this as if we were differentiating $𝑢^{2}$ , where $𝑢 = 𝑦 (𝑥)$ .

The right side is just a function of $𝑥$ , so we can differentiate it as we would with any other function:

{(𝑥^{3} + 7)}^{'} = 3 𝑥^{2}

Our differentiated equation is:

2 𝑦 (𝑥) \cdot 𝑦^{'} (𝑥) = 3 𝑥^{2}

Solving for $𝑚 = 𝑦^{'} (𝑥)$ :

𝑦^{'} (𝑥) = \frac{3 𝑥^{2}}{2 𝑦 (𝑥)} = 𝑚

Notice that the tangent’s slope depends on both $𝑥$ and $𝑦$ , which makes sense because we’d have two different slopes otherwise:

\frac{3 𝑥^{2}}{2 𝑦 (𝑥)} = \pm \frac{3 𝑥^{2}}{2 \sqrt{𝑥^{3} + 7}}

And we have our tangent equation for $𝑥_{𝐺}$ and $𝑦_{𝐺}$ :

\begin{aligned} 𝑡 : 𝑦 & = 𝑚 (𝑥 - 𝑥_{𝐺}) + 𝑦_{𝐺} \\ = \frac{3 𝑥_{𝐺}^{2}}{2 𝑦_{𝐺}} (𝑥 - 𝑥_{𝐺}) + 𝑦_{𝐺} \end{aligned}

Working with finite fields

Elliptic curves are defined over a finite field, which means that all operations are done modulo a prime number $𝑝$ . This is done to ensure that the curve has a finite number of points, which is necessary for cryptographic applications.

References and Suggested readings

A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography
Nick Sullivan
cloudflare.com
Elliptic Curve Cryptography (ECC)
Svetlin Nakov
cryptobook.nakov.com

Lagrange Interpolation Primer

2024-11-29T00:00:00.000Z

You may remember, when in High School, being asked to find the equation of a line that goes through two points. The process was straightforward: you would calculate the slope $𝑎$ and the intercept $𝑏$ of the line $𝑓 (𝑥) = 𝑎 𝑥 + 𝑏$ .

This is a simple example of polynomial interpolation, where we are trying to find a polynomial that goes through a set of points. While the process is simple for a line, it becomes slightly more complex for higher degree polynomials.

Polynomials

One of the most, if not the most important property of polynomials, is that each one of them can uniquely be described by $𝑛 + 1$ points for a polynomial of degree $𝑛$ , noted $𝑓 (𝑥) \in ℙ_{𝑛}$ .

The most straightforward way of seeing this is by setting an equation for each point $𝐴_{𝑖} (𝑥_{𝑖}, 𝑦_{𝑖})$ we have:

\begin{matrix} 𝑃_{𝑛} (𝑥) = 𝑢_{0} + 𝑢_{1} 𝑥 + \dots + 𝑢_{𝑛} 𝑥^{𝑛} = 𝑓 (𝑥) \\ {\begin{cases} 𝑓 (𝑥_{0}) = 𝑦_{0} \\ 𝑓 (𝑥_{1}) = 𝑦_{1} \\ \dots \\ 𝑓 (𝑥_{𝑛}) = 𝑦_{𝑛} \end{cases} \end{matrix}

We can see that we have $𝑛 + 1$ equations for $𝑛 + 1$ factors of $𝑥$ , noted $𝑢_{𝑖} | 0 \leq 𝑖 \leq 𝑛$ , which could also be represented with the following Vandermonde matrix equation:

(\begin{matrix} 1 & 𝑥_{0} & 𝑥_{0}^{2} & \dots & 𝑥_{0}^{𝑛} \\ 1 & 𝑥_{1} & 𝑥_{1}^{2} & \dots & 𝑥_{1}^{𝑛} \\ ⋮ & ⋮ & ⋮ & ⋱ & ⋮ \\ 1 & 𝑥_{𝑛} & 𝑥_{𝑛}^{2} & \dots & 𝑥_{𝑛}^{𝑛} \end{matrix}) (\begin{matrix} 𝑢_{0} \\ 𝑢_{1} \\ ⋮ \\ 𝑢_{𝑛} \end{matrix}) = (\begin{matrix} 𝑦_{0} \\ 𝑦_{1} \\ ⋮ \\ 𝑦_{𝑛} \end{matrix})

Written as $𝑉 𝑢 = 𝑦$ , we can solve this by inverting $𝑉$ :

𝑢 = 𝑉^{- 1} 𝑦

This is doable by applying the Jordan-Gauss algorithm to the augmented matrix $𝑉 | 𝐼$ , where $𝐼$ is the identity matrix (diagonal filled with $1$ s), until we only have pivots equal to $1$ :

(\begin{matrix} 1 & 𝑥_{0} & 𝑥_{0}^{2} & \dots & 𝑥_{0}^{𝑛} & 1 & 0 & \dots & 0 \\ 1 & 𝑥_{1} & 𝑥_{1}^{2} & \dots & 𝑥_{1}^{𝑛} & 0 & 1 & \dots & 0 \\ ⋮ & ⋮ & ⋮ & ⋱ & ⋮ & ⋮ & ⋮ & ⋱ & ⋮ \\ 1 & 𝑥_{𝑛} & 𝑥_{𝑛}^{2} & \dots & 𝑥_{𝑛}^{𝑛} & 0 & 0 & \dots & 1 \end{matrix})

If you prefer to see this in a graphical way, let’s consider the following example:

We have two points $𝐴_{0} (1, 2)$ and $𝐴_{1} (- 2, - 3)$ . We can represent them as follows:

A figure is shown on the site.

It is visually obvious that we can only draw a single line that goes through both points.

A figure is shown on the site.

A line is essentially just $𝑓 (𝑥) = 𝑎 𝑥 + 𝑏$ , which is of degree $1$ . We can guess and deduce we need at least $𝑛 + 1$ points to describe a polynomial function $𝑓 (𝑥) \in ℙ_{𝑛}$ .

The same goes if we add a third point $𝐴_{2} (0, 4)$ :

A figure is shown on the site.

If we did not add this third point and still tried to find a polynomial $𝑃_{2} (𝑥)$ , we would have an infinite number of solutions:

A figure is shown on the site.

But now the question is: how do we actually find the polynomial that goes through all the points? This is where Lagrange interpolation comes into play.

Lagrange Interpolation

Let’s take $𝐴_{0} (0, 1)$ , $𝐴_{1} (1, 3)$ , $𝐴_{2} (2, 2)$ and $𝐴_{3} (3, 4)$ to demonstrate this method.

A figure is shown on the site.

The main principle behind this is to split the wanted function into multiple sub-functions $𝑙_{𝑖} (𝑥)$ , that each contribute to one given point, also called “node”.

We want to construct $𝑙_{𝑖} (𝑥)$ so that:

𝑙_{𝑖} (𝑥) = {\begin{cases} 1 if 𝑥 = 𝑥_{𝑖} \\ 0 if 𝑥 = 𝑥_{𝑗} | 𝑗 \neq 𝑖 \end{cases}

Making a function equal to $0$ at a certain point $𝑥_{𝑗}$ is as simple as multiplying it by $(𝑥 - 𝑥_{𝑗})$ . Based on this property, we can already “guess” $𝑙_{1}^{*} (𝑥)$ :

𝑙_{1}^{*} (𝑥) = (𝑥 - 0) (𝑥 - 2) (𝑥 - 3)

A figure is shown on the site.

Why does multiplying by

$(𝑥 - 𝑥_{𝑗})$ add a root ?

For a function $𝑓 (𝑥) = (𝑥 - 𝑥_{𝑗}) \cdot 𝑔 (𝑥) | 𝑔 (𝑥) \leftarrow ℝ [𝑥]$ , when $𝑥 = 𝑥_{𝑗}$ :

𝑓 (𝑥_{𝑗}) = (𝑥_{𝑗} - 𝑥_{𝑗}) \cdot 𝑔 (𝑥) = 0 \cdot 𝑔 (𝑥) = 0

That’s a good start! But we have a problem: $𝑙_{1}^{*} (𝑥)$ is not equal to $1$ at $𝑥 = 1$ . We can fix this by dividing $𝑙_{1}^{*} (𝑥)$ by $𝑙_{1}^{*} (1)$ :

\begin{aligned} 𝑙_{1} (𝑥) & = \frac{𝑙_{1}^{*} (𝑥)}{𝑙_{1}^{*} (1)} \\ = \frac{(𝑥 - 0) (𝑥 - 2) (𝑥 - 3)}{(1 - 0) (1 - 2) (1 - 3)} \\ = \frac{(𝑥 - 0) (𝑥 - 2) (𝑥 - 3)}{2} \end{aligned}

And we effectively have $𝑙_{1} (1) = 1$ . We can now repeat this process for $𝑙_{0} (𝑥)$ , $𝑙_{2} (𝑥)$ and $𝑙_{3} (𝑥)$ :

A figure is shown on the site.

The polynomial $𝑓 (𝑥) \in ℙ_{3}$ is computed by summing all the $𝑙_{𝑖} (𝑥)$ together and multiplying them by the corresponding $𝑦_{𝑖}$ :

\begin{aligned} 𝑓 (𝑥) & = 𝑦_{0} 𝑙_{0} (𝑥) + 𝑦_{1} 𝑙_{1} (𝑥) + 𝑦_{2} 𝑙_{2} (𝑥) + 𝑦_{3} 𝑙_{3} (𝑥) \\ = 1 \cdot 𝑙_{0} (𝑥) + 3 \cdot 𝑙_{1} (𝑥) + 2 \cdot 𝑙_{2} (𝑥) + 4 \cdot 𝑙_{3} (𝑥) \end{aligned}

A figure is shown on the site.

And we have our final polynomial which effectively goes through all the points:

A figure is shown on the site.

Generalizing this process, we can write the function $𝑓 (𝑥) \in ℙ_{𝑛} (𝑥)$ that goes through $𝑛 + 1$ points $𝐴_{𝑖} (𝑥_{𝑖}, 𝑦_{𝑖})$ :

\begin{aligned} 𝑓 (𝑥) & = \sum_{𝑖 = 0}^{𝑛} 𝑦_{𝑖} 𝑙_{𝑖} (𝑥) \\ = \sum_{𝑖 = 0}^{𝑛} 𝑦_{𝑖} \prod_{𝑗 = 0, 𝑗 \neq 𝑖}^{𝑛} \frac{𝑥 - 𝑥_{𝑗}}{𝑥_{𝑖} - 𝑥_{𝑗}} \end{aligned}

Using ECC for (Multi-)Signatures

2024-11-29T00:00:00.000Z

[!NOTE] I am not a cryptographer, nor a mathematician. This article is the result of my own research and understanding of the subject. If you find any mistakes, please let me know!

The vast majority of what is written here is taken from various sources, which are listed at the end of this article. I highly recommend you to read them if you want to dive deeper into the subject.

Elliptic curves may not write your emails, but they can help prove you sent them. Our goal is to output a signature $(𝑟, 𝑠)$ for a given message $𝑚$ , so that the recipient can verify that the sender is authentic. The sender’s keys are $(𝑝, 𝑃)$ , with $𝑝$ the private key, and $𝑃$ the public one.

ECDSA Signatures

Let’s take a look at the Elliptic Curve Digital Signature Algorithm (ECDSA).

Compute the hash $ℎ = 𝐻 (𝑚)$ where $𝐻 (𝑥)$ is any cryptographic hash function (e.g. SHA-256).
Generate a random $𝑘$ number in in the current subgroup.
Calculate the associated random point on the curve $𝐾 = 𝑘 \cdot 𝐺$ , with $𝐺$ a generator, with $𝑥_{𝐾}$ the $𝑥$ -coordinate of this point.
Calculate the signature $𝑠 = 𝑘^{- 1} \cdot (ℎ + 𝑥_{𝐾} \cdot 𝑝)$ , where $𝑘^{- 1}$ is the modular inverse of $𝑘$ .

By sending $(𝑟, 𝑠)$ , you confirm you know:

The content of the message $𝑚$
The private key $𝑝$ associated to $𝑃 = 𝑝 \cdot 𝐺$

The verifier may follow this procedure to check if the message $𝑚$ that he received along with $(𝑟, 𝑠)$ is authentic:

Compute the hash $ℎ = 𝐻 (𝑚)$ with the same cryptographic hash function defined before.
Calculate the modular inverse of $𝑠$ : $𝑆 = 𝑠^{- 1}$
Recover the random point used in the signature process: $𝐾 = ℎ 𝑆 \cdot 𝐺 + 𝑟 𝑆 \cdot 𝑃$
Check whether $𝑥_{𝐾} = 𝑟$ , if so, then the message is authentic.

To prove this works, let’s start with the definition of the signature $𝑠$ :

\begin{aligned} 𝑠 = 𝑘^{- 1} \cdot (ℎ + 𝑥_{𝐾} \cdot 𝑝) \\ ⟺ & 𝑠 \cdot 𝑘 = ℎ + 𝑥_{𝐾} \cdot 𝑝 \\ ⟺ & \underset{(𝑎)}{\underset{⏟}{𝑠 \cdot 𝑘 = ℎ + 𝑟 \cdot 𝑝}} \end{aligned}

Incorporate $(𝑎)$ into $𝐾$ :

\begin{aligned} 𝐾 & = ℎ 𝑆 \cdot 𝐺 + 𝑟 𝑆 \cdot 𝑃 \\ = ℎ 𝑠^{- 1} \cdot 𝐺 + 𝑟 𝑠^{- 1} \cdot (𝑝 \cdot 𝐺) \\ = 𝑠^{- 1} (ℎ \cdot 𝐺 + 𝑟 \cdot (𝑝 \cdot 𝐺)) \\ = 𝑠^{- 1} \underset{(𝑎)}{\underset{⏟}{(ℎ + 𝑟 \cdot 𝑝)}} \cdot 𝐺 \\ = \underset{= 1}{\underset{⏟}{𝑠^{- 1} 𝑠}} \cdot 𝑘 \cdot 𝐺 \\ = 𝑘 \cdot 𝐺 \end{aligned}

Which is just our definition of $𝐾$ when generating the signature.

Cool Kids Public Key Recovery

Let’s suppose you are talking through a Tin can telephone with your friend and every byte you send matters. You don’t want to send the public key $𝑃$ along with the signature $(𝑟, 𝑠)$ because that’s just too much data. Instead, you can recover the public key from the signature and the message.

Given $𝑥_{𝐾}$ , there are typically two candidate points $𝐾_{𝑖}^{'}$ that fit. And since we know that $𝐾 = ℎ 𝑆 \cdot 𝐺 + 𝑟 𝑆 \cdot 𝑃$ , which we just verified works, it can be rearranged to isolate the public key $𝑃$ :

\begin{aligned} 𝐾_{𝑖}^{'} & = ℎ 𝑆 \cdot 𝐺 + 𝑟 𝑆 \cdot 𝑃_{𝑖} \\ ⟺ 𝑃_{𝑖} & = 𝑠^{- 1} (𝑟 𝐾_{𝑖}^{'} - ℎ 𝐺) \end{aligned}

To choose which one is the correct one, we need to verify the signature with each $𝑃_{𝑖}$ :

\begin{matrix} 𝐾_{𝑖} = ℎ 𝑆 \cdot 𝐺 + 𝑟 𝑆 \cdot 𝑃_{𝑖} = (𝑥_{𝐾}, 𝑦_{𝐾}) \\ 𝑥_{𝐾} \overset{?}{=} 𝑟 \end{matrix}

This ambiguity is often removed by adding a single bit $𝑏 \in {0, 1}$ into the signature message: $(𝑟, 𝑠, 𝑏)$

Schnorr Signatures

Schnorr signatures are a bit like ECDSA, but faster and simpler. We are going to use the same keys $(𝑝, 𝑃)$ as before, with $𝑝$ the private key and $𝑃$ the public one. We’ll first see the procedure and then discuss the mathematical proof of why this works.

Sample a random nonce $𝑟 \leftarrow ℤ_{𝑛}$

What the hell is

$ℤ_{𝑛}$ ?

The set $ℤ_{𝑛}$ is a cyclic group of integers, isomorphic to the quotient group $ℤ / 𝑛 ℤ$ . It is basically just the set of integers modulo $𝑛$ .

ℤ_{𝑛} = {0, 1, 2, \dots, 𝑛 - 1}

In our case, $𝑛$ is the order (how many points are in) of the subgroup generated by $𝐺$ . If the curve’s cofactor $ℎ$ is 1, then $𝑛$ is the order of the curve. If $ℎ$ is not 1, the order is $\frac{𝑛}{ℎ} = ord (𝐺)$

Multiply it by the generator: $𝑅 = 𝑟 𝐺$
We can now compute the challenge $𝑒 = 𝐻 (𝑅 ‖ 𝑃 ‖ 𝑚)$
And the signature: $𝑠 = 𝑟 + 𝑒 𝑝$

The final signature is $(𝑅, 𝑠)$ .

Once the signature has been emitted, verifying it is as easy as checking:

𝑠 \cdot 𝐺 = 𝑅 + 𝑒 𝑃

To know $𝑒$ , the verifier needs to know the message $𝑚$ , the public key $𝑃$ . In some cases, you might not need to include the public key into the challenge and simply hash $𝑒 = 𝐻 (𝑅 ‖ 𝑚)$ .

Why it Works

There isn’t really a proof needed for the verifying step as it’s just factoring out $𝐺$ , but here you are:

\begin{aligned} 𝑠 \cdot 𝐺 = 𝑅 + 𝑒 𝑃 \\ ⟺ & 𝑠 \cdot 𝐺 = \underset{𝑅}{\underset{⏟}{𝑟 𝐺}} + ℎ \underset{𝑃}{\underset{⏟}{𝑝 𝐺}} \\ ⟺ & 𝑠 \cdot 𝐺 = (𝑟 + 𝑒 𝑝) \cdot 𝐺 \end{aligned}

One trickier part is to explain why we are adding a random nonce $𝑟$ to both the signature and the challenge. This value has to be sampled randomly and must not be reused. If it is, the private key can be recovered. Let’s first take the case where no $𝑟$ is used:

\begin{aligned} 𝑠 = 𝑒 𝑝 \\ ⟺ & 𝑝 = 𝑠^{- 1} 𝑒 \end{aligned}

Recovering the private key is as simple as multiplying the challenge $𝑒$ by the modular inverse of $𝑠$ . Not good.

Now, let’s take the case where $𝑟$ is reused, with two messages $𝑚_{1}$ and $𝑚_{2}$ , along with their respective signatures $(𝑅, 𝑠_{1})$ and $(𝑅, 𝑠_{2})$ :

{\begin{cases} 𝑠_{1} = 𝑟 + 𝑒_{1} 𝑝 ⟺ 𝑟 = (𝑠_{1} - 𝑒_{1} 𝑝) (𝑎) \\ 𝑠_{2} = 𝑟 + 𝑒_{2} 𝑝 ⟺ 𝑟 = (𝑠_{2} - 𝑒_{2} 𝑝) (𝑏) \end{cases}

Combining $(𝑎)$ and $(𝑏)$ :

\begin{aligned} 𝑟 = (𝑠_{1} - 𝑒_{1} 𝑝) = (𝑠_{2} - 𝑒_{2} 𝑝) \\ ⟺ & 𝑒_{1} 𝑝 - 𝑒_{2} 𝑝 = 𝑠_{1} - 𝑠_{2} \\ ⟺ & 𝑝 \cdot (𝑒_{1} - 𝑒_{2}) = 𝑠_{1} - 𝑠_{2} \\ ⟺ & 𝑝 = \frac{𝑠_{1} - 𝑠_{2}}{𝑒_{1} - 𝑒_{2}} \end{aligned}

You may see $𝑟$ as an additional unknown variable that is used to prevent the linear equation system from being solved, because for $𝑛$ messages, you have $𝑛$ equations and $𝑛 + 1$ unknowns, which is unsolvable in our case.

Aggregating Signatures

Schnorr signatures have the nice property that they can be aggregated, this means that a group of people can sign a message $𝑚$ together and the signature can be verified as if it was signed by a single person. Let’s consider our signing group $𝑆 = {𝑎, 𝑏, 𝑐}$ for Alice, Bob and Charlie respectively.

\begin{aligned} Alice & Bob & Charlie \\ 𝑅_{𝑎} = 𝑟_{𝑎} \cdot 𝐺 & 𝑅_{𝑏} = 𝑟_{𝑏} \cdot 𝐺 & 𝑅_{𝑐} = 𝑟_{𝑐} \cdot 𝐺 \end{aligned}

The aggregated nonce is simply the sum of all nonces:

\begin{aligned} 𝑅 & = \sum_{𝑖 \in 𝑆} 𝑅_{𝑖} \\ = 𝑅_{𝑎} + 𝑅_{𝑏} + 𝑅_{𝑐} \\ = (𝑟_{𝑎} + 𝑟_{𝑏} + 𝑟_{𝑐}) \cdot 𝐺 \end{aligned}

Likewise for the public key:

\begin{aligned} 𝑃 & = \sum_{𝑖 \in 𝑆} 𝑃_{𝑖} \\ = 𝑃_{𝑎} + 𝑃_{𝑏} + 𝑃_{𝑐} \\ = (𝑝_{𝑎} + 𝑝_{𝑏} + 𝑝_{𝑐}) \cdot 𝐺 \end{aligned}

Each of them computes the challenge $𝑒$ along with the final signature $𝑠_{𝑖}$ with the parameters just agreed upon:

\begin{matrix} 𝑒 = 𝐻 (𝑅 ‖ 𝑃 ‖ 𝑚) \\ 𝑠_{𝑖} = 𝑒 𝑝_{𝑖} + 𝑟_{𝑖} \end{matrix}

Everyone now sends their $𝑠_{𝑖}$ to the group.

And aggregate again:

𝑠 = \sum_{𝑖 \in 𝑆} 𝑠_{𝑖}

Because we are just adding signatures parts together, we can group the nonces and the private keys in our final signature:

\begin{aligned} 𝑠 & = \sum_{𝑖 \in 𝑆} 𝑠_{𝑖} \\ = \sum_{𝑖 \in 𝑆} (𝑒 𝑝_{𝑖} + 𝑟_{𝑖}) \\ = 𝑒 𝑝_{𝑎} + 𝑟_{𝑎} + 𝑒 𝑝_{𝑏} + 𝑟_{𝑏} + 𝑒 𝑝_{𝑐} + 𝑟_{𝑐} \\ = \underset{Nonces}{\underset{⏟}{𝑟_{𝑎} + 𝑟_{𝑏} + 𝑟_{𝑐}}} + 𝑒 \underset{Private Keys}{\underset{⏟}{(𝑝_{𝑎} + 𝑝_{𝑏} + 𝑝_{𝑐})}} \\ = \sum_{𝑖 \in 𝑆} 𝑟_{𝑖} + 𝑒 \cdot \sum_{𝑖 \in 𝑆} 𝑝_{𝑖} \end{aligned}

In the verifying step, multiplying each side by $𝐺$ :

\begin{aligned} 𝑠 𝐺 & = \sum_{𝑖 \in 𝑆} 𝑟_{𝑖} \cdot 𝐺 + 𝑒 \cdot \sum_{𝑖 \in 𝑆} 𝑝_{𝑖} \cdot 𝐺 \\ = \sum_{𝑖 \in 𝑆} 𝑅_{𝑖} + 𝑒 \cdot \sum_{𝑖 \in 𝑆} 𝑃_{𝑖} \\ = 𝑅 + 𝑒 𝑃 \end{aligned}

But wait!

At no point in this procedure, we ever check if the nonces or the public keys provided are honest. What if Charlie provided a malicious key $𝑃_{𝑐}^{*}$ in the sharing step ? Because everyone doesn’t send their public key at the exact same time, Carol could wait for everyone to send theirs, and compute:

𝑃_{𝑐}^{*} = 𝑃_{𝑐} - 𝑃_{𝑎} - 𝑃_{𝑏}

The aggregated key will look like:

\begin{aligned} 𝑃 & = \sum_{𝑖 \in 𝑆} 𝑃_{𝑖} \\ = 𝑃_{𝑎} + 𝑃_{𝑏} + 𝑃_{𝑐}^{*} \\ = 𝑃_{𝑎} + 𝑃_{𝑏} + (𝑃_{𝑐} - 𝑃_{𝑎} - 𝑃_{𝑏}) \\ = 𝑃_{𝑐} \end{aligned}

Carol just wiped everyone else from the signing key, and is now in full control of the signature. How can we prevent that ?

Multi-Signatures, don’t trust, verify

The most common way to prevent this is to force everyone to provide a proof that their public key is honest. This is done by providing a Proof of Knowledge for the private key, proving that they know the private key associated to the public key they provided.

Let’s take the case of a prover Patricia and a verifier Victor. Patricia wants to prove that she knows the private key $𝑝$ associated to the public key $𝑃 = 𝑝 \cdot 𝐺$ . The proof is done in four steps:

Patricia samples $𝑟 \leftarrow ℤ_{𝑛}$ at random and sends $𝑅 = 𝑟 \cdot 𝐺$ to Victor.
Victor sends a challenge $𝑐 \leftarrow ℤ_{𝑛}$ to Patricia.
Patricia computes $𝑧 = 𝑟 + 𝑐 𝑝$ and sends it to Victor.
Victor verifies that $𝑧 \cdot 𝐺 = 𝑅 + 𝑐 𝑃$ .

This works because:

\begin{aligned} 𝑧 & = 𝑟 + 𝑐 𝑝 \\ 𝑧 \cdot 𝐺 & = (𝑟 + 𝑐 𝑝) \cdot 𝐺 \\ = 𝑟 \cdot 𝐺 + 𝑐 𝑝 \cdot 𝐺 \\ = 𝑅 + 𝑐 𝑃 \end{aligned}

But what if Patricia doesn’t know the associated private key but still wants to prove that her key is honest ? Remember commitment schemes ? We can use them here. In our case, every participant will commit to their public key before disclosing it. Think of it as putting your public key in a box, sealing it and waiting for everyone to do the same before opening it. Let’s get back to our group $𝑆 = {𝑎, 𝑏, 𝑐}$ :

Each participant $𝑖$ hashes their public key $𝑃_{𝑖}$ and sends $𝐻 (𝑃_{𝑖})$ to everyone.
Once everyone has sent their hash, they disclose their public key $𝑃_{𝑖}$ .
Everyone verifies that the hash they received matches the public key.
The signing process continues as usual.

This way, everyone can be sure that the public keys are honest and that no one is trying to pull a fast one.

There’s more!

Random nonces are also aggregated, and at no point we are verifying that they are authentic. The exploit method is a bit trickier, I recommend you to read this article by conduition on the subject if you want to know the details.

References and Suggested readings

Practical Cryptography for Developers - Digital Signatures
Svetlin Nakov
cryptobook.nakov.com
A Dive Into the Math Behind Bitcoin Schnorr Signatures
conduition.io
Wagner’s Birthday Attack - How to Break InsecureMuSig
conduition.io
How to Prove Schnorr Assuming Schnorr: Security of Multi- and Threshold Signatures
Elizabeth Crites, Chelsea Komlo, and Mary Maller
eprint.iacr.org

Shamir Secret Sharing in a Nutshell

2024-11-29T00:00:00.000Z

[!NOTE] I am not a cryptographer, nor a mathematician. This article is the result of my own research and understanding of the subject. If you find any mistakes, please let me know!

The vast majority of what is written here is taken from various sources, which are listed at the end of this article. I highly recommend you to read them if you want to dive deeper into the subject.

The main idea behind Shamir Secret Sharing (SSS) is to split a secret $𝑠$ into $𝑛$ parts, such that any $𝑘$ parts can be used to reconstruct the secret, but any $𝑘 - 1$ parts are not enough to do so, and do not give any information about the secret.

Splitting the Secret

Let’s take the following example: we want to split the secret $𝑠 = 42$ into $𝑛 = 5$ parts, such that any $𝑘 = 3$ parts can be used to reconstruct the secret. It is supposed we are working in a finite field $𝔽_{𝑞}$ for the entirety of this post.

What the hell is

$𝔽_{𝑞}$ ?

A finite field $𝔽_{𝑞}$ where $𝑞 = 𝑝^{𝑘} | 𝑝 \in 𝒫︀$ ( $𝑞$ is a prime power), is a finite set of elements, on which we can apply our usual additions and multiplications.

The most common finite field is the set of integers modulo $𝑞$ , $ℤ / 𝑞 ℤ = ℤ_{𝑞}$ , where all computations are taken $mod 𝑞$ , which means that we have:

ℤ_{𝑞} = {0, 1, 2, \dots, 𝑞 - 1}

In the case of an elliptic curve, $𝑞$ is our curve’s order.

The first step is to sample a random polynomial $𝑓 (𝑥) = 𝑃_{𝑘 - 1} (𝑥) = 𝑎_{0} + 𝑎_{1} 𝑥 + \dots + 𝑎_{𝑘 - 1} 𝑥^{𝑘 - 1}$ of degree $𝑘 - 1$ such that $𝑎_{0} = 𝑠$ . This gives us the property $𝑓 (0) = 𝑠$ .

𝑓 (𝑥) = 𝑃_{2} (𝑥) = 42 + 5 𝑥 + 3 𝑥^{2}

Our splits, also called shares, are in fact just points of our polynomial. We can generate them by evaluating $𝑓 (𝑥)$ for $𝑥 \in 𝑆 = {1, 2, 3, 4, 5}$ . Do not evaluate for $𝑥 = 0$ as this would obviously just give away the secret.

\begin{aligned} 𝑧_{1} & = 𝑓 (1) = 42 + 5 + 3 & = & 50 \\ 𝑧_{2} & = 𝑓 (2) = 42 + 10 + 12 & = & 64 \\ 𝑧_{3} & = 𝑓 (3) = 42 + 15 + 27 & = & 84 \\ 𝑧_{4} & = 𝑓 (4) = 42 + 20 + 48 & = & 110 \\ 𝑧_{5} & = 𝑓 (5) = 42 + 25 + 75 & = & 142 \end{aligned}

Thus, our shares are $𝑍_{1} (1, 50)$ , $𝑍_{2} (2, 64)$ , $𝑍_{3} (3, 84)$ , $𝑍_{4} (4, 110)$ and $𝑍_{5} (5, 142)$ .

Let’s now plot the polynomial $𝑓 (𝑥)$ :

A figure is shown on the site.

Reconstructing the Secret

We know that $𝑛 + 1$ points $𝑍_{𝑖} (𝑥_{𝑖}, 𝑦_{𝑖}) | 𝑖 \in 𝑆$ will suffice to construct the polynonial $𝑃_{𝑛} (𝑥)$ of degree $𝑛$ .

In our case, $deg (𝑓 (𝑥)) = 𝑘 - 1$ , so we need $(𝑘 - 1) + 1 = 𝑘$ points to restore $𝑓 (𝑥)$ , just as described in the beginning.

Based on the shares we generated earlier, let’s take $𝑍_{1} (1, 50)$ , $𝑍_{3} (3, 84)$ and $𝑍_{5} (5, 142)$ (our recovery group $𝑅 = {1, 3, 5}$ ) to reconstruct the polynomial $𝑓 (𝑥)$ using Lagrange interpolation:

[!TIP] If you’re curious about Lagrange interpolation, I have written a quick explaination for you to read.

𝑓 (𝑥) = \sum_{𝑖 \in 𝑅} 𝑦_{𝑖} \cdot \overset{𝑙_{𝑖 (𝑥)}}{\overset{⏞}{\prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{𝑥 - 𝑥_{𝑖}}{𝑥_{𝑖} - 𝑥_{𝑗}}}}

\begin{aligned} 𝑓 (𝑥) & = 50 \cdot \frac{(𝑥 - 3) (𝑥 - 5)}{(1 - 3) (1 - 5)} + 84 \cdot \frac{(𝑥 - 1) (𝑥 - 5)}{(3 - 1) (3 - 5)} + 142 \cdot \frac{(𝑥 - 1) (𝑥 - 3)}{(5 - 1) (5 - 3)} \\ = \frac{25}{4} (𝑥 - 5) (𝑥 - 3) + \frac{71}{4} (𝑥 - 1) (𝑥 - 3) - 21 (𝑥 - 5) (𝑥 - 1) \\ = 42 + 5 𝑥 + 3 𝑥^{2} \end{aligned}

It’s even cooler when represented graphically:

A figure is shown on the site.

Commitments, Proofs and Verifications

In a perfect world where everyone is honest and where there are no transmission errors caused by cosmic rays, we could just send the shares to the participants and call it a day. But guess what? Sh*t happens.

We need a way to check that the share we receive as a shareholder after the secret has been split is actually a valid one. You could gather with other bearers and collectively verify if the recovered secret is correct, but that is just too much hassle for such a simple task.

Instead, let’s take advantage of the properties of elliptic curves to create a commitment scheme. After we have generated our polynomial $𝑓 (𝑥)$ , we can take each coefficient $𝑎_{𝑖}$ and multiply it by the generator point $𝐺$ of the curve. This gives us a few values $𝐶 = {𝜙_{0}, 𝜙_{1}, \dots, 𝜙_{𝑘 - 1}} | 𝜙_{𝑖} = 𝑎_{𝑖} \cdot 𝐺$ that we can send to the shareholders.

[!TIP] If you are not familiar with basic elliptic curve stuff, I recommend that you read my post on the subject or the references listed at the end of this article.

When a shareholder wants to verify their share $𝑍_{𝑖} = (𝑖, 𝑓 (𝑖))$ , they can check with the following equation:

\begin{aligned} 𝑓 (𝑖) \cdot 𝐺 & = \sum_{𝑗 = 0}^{𝑘 - 1} (𝜙_{𝑗} \cdot 𝑖^{𝑗}) \\ = 𝜙_{0} + 𝜙_{1} 𝑖 + 𝜙_{2} 𝑖^{2} + \dots + 𝜙_{𝑘 - 1} 𝑖^{𝑘 - 1} \\ = 𝑎_{0} \cdot 𝐺 + (𝑎_{1} \cdot 𝐺) 𝑖 + (𝑎_{2} \cdot 𝐺) 𝑖^{2} + \dots + (𝑎_{𝑘 - 1} \cdot 𝐺) 𝑖^{𝑘 - 1} \\ = (𝑎_{0} + 𝑎_{1} 𝑖 + 𝑎_{2} 𝑖^{2} + \dots + 𝑎_{𝑘 - 1} 𝑖^{𝑘 - 1}) \cdot 𝐺 \\ = \sum_{𝑗 = 0}^{𝑘 - 1} (𝑎_{𝑗} 𝑖^{𝑗}) \cdot 𝐺 \\ = 𝑓 (𝑖) \cdot 𝐺 \end{aligned}

You could see this procedure as computing the “public keys” of the coefficients. This method is also called “Feldman’s Verifiable Secret Sharing”.

One may argue that disclosing $𝑎_{0} \cdot 𝐺 = 𝑠 \cdot 𝐺$ could give information about the polynomial, but if we suppose that $𝑠$ is an EC secret key, the public key $𝑠 \cdot 𝐺$ is supposed public and may be shared. Finding $𝑠$ with $𝑠 \cdot 𝐺$ comes down to solving the discrete logarithm problem, which is supposed really hard here.

Verifying that $𝑓 (0)$ is a private key

We know some public key $𝑃 = 𝑝 \cdot 𝐺$ and we want to verify that the secret being shared is actually the private key $𝑝$ . This can be done by first checking if the commitments $𝐶 = {𝜙_{0}, 𝜙_{1}, \dots, 𝜙_{𝑘 - 1}}$ are valid, and then verifying that $𝜙_{0} = 𝑝 \cdot 𝐺 = 𝑃$ .

\land {\begin{cases} 𝑓 (𝑗) \cdot 𝐺 \overset{?}{=} \sum_{𝑖 = 0}^{𝑘 - 1} 𝜙_{𝑖} \cdot 𝑗^{𝑖} \\ 𝜙_{0} = 𝑝 \cdot 𝐺 = 𝑃 \end{cases} ⟺ The secret is 𝑝

Another way the dealer could commit to the polynomial he generated without directly sharing $𝑠 \cdot 𝐺$ , is to add a so-called “blinding polynomial”, a pretty common concept in cryptography.

Let’s now instead take $𝜙_{𝑖} = 𝑎_{𝑖} \cdot 𝐺 + 𝑏_{𝑖} \cdot 𝐻$ where $𝑏_{𝑖}$ comes from a randomly generated polynomial $𝑔 (𝑥) = 𝑏_{0} + 𝑏_{1} 𝑥 + \dots + 𝑏_{𝑘 - 1} 𝑥^{𝑘 - 1}$ , our blinding polynomial. $𝐻 \neq 𝐺$ is just another generator point on the curve. The dealer will now needs to distribute slightly different shares $𝑍_{𝑖} = (𝑖, 𝑓 (𝑖), 𝑔 (𝑖))$ .

Shareholders may now verify their shares with:

\begin{aligned} 𝑓 (𝑖) \cdot 𝐺 + 𝑔 (𝑖) \cdot 𝐻 & = \sum_{𝑗 = 0}^{𝑘 - 1} (𝜙_{𝑗} \cdot 𝑖^{𝑗}) \\ = \sum_{𝑗 = 0}^{𝑘 - 1} ((𝑎_{𝑖} \cdot 𝐺 + 𝑏_{𝑖} \cdot 𝐻) \cdot 𝑖^{𝑗}) \\ = \sum_{𝑗 = 0}^{𝑘 - 1} (𝑎_{𝑗} 𝑖^{𝑗}) \cdot 𝐺 + \sum_{𝑗 = 0}^{𝑘 - 1} (𝑏_{𝑗} 𝑖^{𝑗}) \cdot 𝐻 \\ = 𝑓 (𝑖) \cdot 𝐺 + 𝑔 (𝑖) \cdot 𝐻 \end{aligned}

This second method is known as “Pedersen’s Verifiable Secret Sharing”.

Bob just got hit by a bus, what now?

Our good old friend disappeared along with his share, and now other bearers are scared of losing too many shares until they can’t recover the secret. They could reiterate the dealing procedure by all sending their shares to a single person which then redistributes the new ones. However this is not feasible in the case where everyone distrusts each other. We need a multi-computational way of re-issuing a new share without someone ever recovering the secret.

We will need $𝑘$ shareholders, denoted $𝑅$ to re-issue a new share $𝑍_{ℓ} = (ℓ, 𝑓 (ℓ)) = (ℓ, 𝑧_{ℓ})$ .

Each shareholder begins by computing their Lagrange multiplier:

𝑙_{𝑖} (ℓ) = \prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗}

After multiplying with their share $𝑧_{𝑖} = 𝑓 (𝑖)$ , they randomly split it into $𝑘$ so-called Lagrange-parts $𝜕_{𝑖, 𝑗}$ in order to distribute them to other bearers $𝑗$ :

𝑧_{𝑖} \cdot 𝑙_{𝑖} = 𝜕_{𝑖, 1} + 𝜕_{𝑖, 2} + \dots + 𝜕_{𝑖, 𝑘}

The exchange matrix $𝐸$ can be represented as:

𝐸_{𝑘 \times 𝑘} = (\begin{matrix} 𝜕_{1, 1} & 𝜕_{1, 2} & \dots & 𝜕_{1, 𝑘} \\ 𝜕_{2, 1} & 𝜕_{2, 2} & \dots & 𝜕_{2, 𝑘} \\ ⋮ & ⋮ & ⋱ & ⋮ \\ 𝜕_{𝑘, 1} & 𝜕_{𝑘, 2} & \dots & 𝜕_{𝑘, 𝑘} \end{matrix})

Where the $𝑖$ ^th row corresponds to the Lagrange-parts that the shareholder $𝑖$ will send and the $𝑗$ ^th column to the Lagrange-parts the shareholder $𝑗$ will receive.

Each shareholder $𝑗$ computes the partial-share:

𝜎_{𝑗} = \sum_{𝑖 \in 𝑅} 𝜕_{𝑖, 𝑗}

Where $𝜕_{𝑖, 𝑗}$ is the $𝑗$ ^th Lagrange-part of $𝑖$ . They respectively send $𝜎_{𝑗}$ to the new bearer $ℓ$ , which finally computes his share:

𝑧_{ℓ} = \sum_{𝑖 \in 𝑅} 𝜎_{𝑗}

This can be rewritten as:

\begin{aligned} \sum_{𝑗 \in 𝑅} 𝜎_{𝑗} & = \sum_{𝑗 \in 𝑅} \sum_{𝑖 \in 𝑅} 𝜕_{𝑗, 𝑖} \\ = \sum_{𝑖 \in 𝑅} (\sum_{𝑗 \in 𝑅} 𝜕_{𝑗, 𝑖}) \\ = \sum_{𝑖 \in 𝑅} (𝜕_{1, 𝑖} + 𝜕_{2, 𝑖} + \dots + 𝜕_{3, 𝑖}) \\ = \sum_{𝑖 \in 𝑅} 𝑧_{𝑖} \cdot 𝑙_{𝑖} = 𝑓 (ℓ) \end{aligned}

Inception

Another angle to tackle this problem from is to re-use Secret Sharing inside our Secret Sharing scheme (Inception, anyone?).

Let’s say we have our recovery group $𝑅$ , our new shareholders $𝑁$ and $𝐴 = 𝑅 \cup 𝑁$ for convenience.

Each shareholder $𝑖 \in 𝑅$ generates a random polynomial $𝑔_{𝑖} (𝑥)$ of degree $𝑘 - 1$ .
They each compute the auxiliary shares $𝑑_{𝑖, 𝑗} = 𝑔_{𝑖} (𝑗)$ for $𝑗 \in 𝐴$ .
Every shareholder $𝑗 \in 𝐴$ receives the auxiliary shares $𝑑_{𝑖, 𝑗}$ from the recovery group.
Each shareholder $𝑗 \in 𝑅$ computes the aggregated share $𝐻 (𝑗) = 𝑢_{𝑗} = 𝑧_{𝑗} + \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, 𝑗}$ and shares it to everyone in $𝑁$ .
Each future bearer $ℓ \in 𝑁$ can interpolate the polynomial $𝐻 (𝑥)$ from the shares $𝑢_{𝑗} | 𝑗 \in 𝑅$ and compute their share $𝑧_{ℓ} = 𝐻 (ℓ) - \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, ℓ} = 𝑢_{ℓ} - \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, ℓ}$

Let’s take a look at the math:

\begin{aligned} 𝑧_{ℓ} & = (𝐻 (ℓ) - \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, ℓ}) | ℓ \in 𝑁 \\ = \underset{𝐻 (ℓ)}{\underset{⏟}{\sum_{𝑖 \in 𝑅} (𝑧_{𝑖} + \sum_{𝑘 \in 𝑅} 𝑔_{𝑘} (𝑖)) \cdot \prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗}}} - \sum_{𝑖 \in 𝑅} 𝑔_{𝑖} (ℓ) \\ = \underset{𝑓 (ℓ)}{\underset{⏟}{\sum_{𝑖 \in 𝑅} (𝑧_{𝑖} \cdot \prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗})}} + \sum_{𝑖 \in 𝑅} (\sum_{𝑘 \in 𝑅} 𝑔_{𝑘} (𝑖) \cdot \prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗}) - \sum_{𝑖 \in 𝑅} 𝑔_{𝑖} (ℓ) \\ = 𝑓 (ℓ) + \sum_{𝑘 \in 𝑅} \underset{𝑔_{𝑘} (ℓ)}{\underset{⏟}{\sum_{𝑖 \in 𝑅} 𝑔_{𝑘} (𝑖) \cdot \prod_{𝑗 \in 𝑅, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗}}} - \sum_{𝑖 \in 𝑅} 𝑔_{𝑖} (ℓ) \\ = 𝑓 (ℓ) + \underset{= 0}{\underset{⏟}{\sum_{𝑘 \in 𝑅} 𝑔_{𝑘} (ℓ) - \sum_{𝑖 \in 𝑅} 𝑔_{𝑖} (ℓ)}} \\ = 𝑓 (ℓ) \end{aligned}

But wait! We just learnt how to implement a secure, verifiable secret sharing scheme and we aren’t even using it!

Verifiable Inception

Let’s review the protocol, this time including relevant checks to ensure the data we’re receiving is genuine. We assume the original dealer was a good guy and already used Feldman’s VSS, providing the commitments $𝐶 = {𝜙_{0}, 𝜙_{1}, \dots, 𝜙_{𝑘 - 1}} | 𝜙_{𝑖} = 𝑎_{𝑖} \cdot 𝐺$ for the OG polynomial $𝑓 (𝑥) = 𝑎_{0} + 𝑎_{1} 𝑥 + \dots + 𝑎_{𝑘 - 1} 𝑥^{𝑘 - 1}$ to everyone.

Each shareholder $𝑖 \in 𝑅$ generates a random polynomial $𝑔_{𝑖} (𝑥) = 𝑏_{𝑖, 0} + 𝑏_{𝑖, 1} 𝑥 + \dots + 𝑏_{𝑖, 𝑘 - 1} 𝑥^{𝑘 - 1}$ of degree $𝑘 - 1$ .
They also compute and share for $𝑗 \in 𝑅$ to see their commitments: $Γ_{𝑖} = {𝜓_{𝑖, 0}, 𝜓_{𝑖, 1}, \dots, 𝜓_{𝑖, 𝑘 - 1}} | 𝜓_{𝑖, 𝑗} = 𝑏_{𝑖, 𝑗} \cdot 𝐺$
They each compute the auxiliary shares $𝑑_{𝑖, 𝑗} = 𝑔_{𝑖} (𝑗)$ for $𝑗 \in 𝐴$ , and shares them once they have received all other $Γ_{𝑖} | 𝑖 \in 𝑅$
Every shareholder $𝑗 \in 𝐴$ receives the auxiliary shares $𝑑_{𝑖, 𝑗}$ from $𝑖 \in 𝑅$ and checks whether they match $Γ_{𝑖}$ $\begin{aligned} 𝑑_{𝑖, 𝑗} \cdot 𝐺 & = \sum_{𝑚 = 0}^{𝑘 - 1} 𝜓_{𝑖, 𝑚} \cdot 𝑗^{𝑚} = \sum_{𝑚 = 0}^{𝑘 - 1} 𝑏_{𝑖, 𝑚} \cdot 𝐺 \cdot 𝑗^{𝑚} \\ = \sum_{𝑚 = 0}^{𝑘 - 1} (𝑏_{𝑖, 𝑚} \cdot 𝑗^{𝑚}), 𝑔_{𝑖} (𝑗) \cdot 𝐺 \\ = 𝑔_{𝑖} (𝑗) \cdot 𝐺 \end{aligned}$
Before computing anything else, each shareholder $𝑗 \in 𝑅$ commits to the upcoming $𝐻 (𝑥)$ polynomial and sends it to $𝑖 \in 𝐴$ : $𝑇 = {𝜃_{𝑖}}_{𝑖 \in 𝑅} | 𝜃_{𝑖} = \sum_{𝑘 \in 𝑅} 𝜓_{𝑖, 𝑘}$
Each shareholder $𝑗 \in 𝑅$ computes the aggregated share $𝐻 (𝑗) = 𝑢_{𝑗} = 𝑧_{𝑗} + \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, 𝑗}$ .
Each inductee $𝑖 \in 𝑁$ first waits to receive all $𝑇$ , checks that they are the same from everyone, and then receives $𝑢_{𝑗} | 𝑗 \in 𝑅$ .
Each future shareholder $𝑖 \in 𝑁$ checks whether each given $𝑢_{𝑗} | 𝑗 \in 𝑅$ is genuine: $\begin{aligned} 𝑢_{𝑗} \cdot 𝐺 & = \sum_{𝑖 = 0}^{𝑘 - 1} 𝜙_{𝑖} + \sum_{𝑖 \in 𝑅} 𝜃_{𝑖} \\ = \sum_{𝑖 = 0}^{𝑘 - 1} 𝑎_{𝑖} 𝑗^{𝑖} \cdot 𝐺 + \sum_{𝑖 \in 𝑅} \sum_{𝑚 \in 𝑅} 𝜓_{𝑖, 𝑚} \\ = \sum_{𝑖 = 0}^{𝑘 - 1} 𝑎_{𝑖} 𝑗^{𝑖} \cdot 𝐺 + \sum_{𝑖 \in 𝑅} \sum_{𝑚 \in 𝑅} 𝑏_{𝑖, 𝑚} 𝑗^{𝑚} \cdot 𝐺 \\ = (\sum_{𝑖 = 0}^{𝑘 - 1} 𝑎_{𝑖} 𝑗^{𝑖} + \sum_{𝑖 \in 𝑅} \sum_{𝑚 \in 𝑅} 𝑏_{𝑖, 𝑚} 𝑗^{𝑚}) \cdot 𝐺 \\ = (𝑓 (𝑗) + \sum_{𝑖 \in 𝑅} 𝑔_{𝑖} (𝑗)) \cdot 𝐺 = (𝑧_{𝑗} + \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, 𝑗}) \cdot 𝐺 \\ = 𝐻 (𝑗) \cdot 𝐺 = 𝑢_{𝑗} \cdot 𝐺 \end{aligned}$
Each future bearer $𝑗 \in 𝑁$ can interpolate the polynomial $𝐻 (𝑥)$ from the shares $𝑢_{𝑗}$ and compute their share $𝑧_{𝑗} = 𝐻 (𝑗) - \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, 𝑗} = 𝑢_{𝑗} - \sum_{𝑖 \in 𝑅} 𝑑_{𝑖, 𝑗}$

In the case where we only want to issue a single share, conduition proposed a clever way to remove the subtracting step at the end by adding a root at $ℓ | {ℓ} = 𝑁$ to the blinding polynomial. This way, we have:

𝑔_{𝑖} (𝑥) = (𝑥 - ℓ) \cdot 𝑃_{𝑘 - 2} (𝑥) | 𝑖 \in 𝑆, 𝑃_{𝑘 - 2} (𝑥) \leftarrow 𝔽_{𝑞} [𝑥]

When interpolating $𝐻 (ℓ)$ , the blinding polynomials $𝑔_{𝑖} (ℓ) | 𝑖 \in 𝑆$ cancel out and we directly get $𝑧_{ℓ}$ :

\begin{aligned} 𝑧_{ℓ} & = 𝐻 (ℓ) \\ = \sum_{𝑖 \in 𝑆} (𝑧_{𝑖} + 𝑢_{𝑖}) \cdot \prod_{𝑗 \in 𝑆, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗} \\ = \sum_{𝑖 \in 𝑆} (𝑧_{𝑖} + \sum_{𝑚 \in 𝑆} 𝑔_{𝑚} (𝑖)) \cdot \prod_{𝑗 \in 𝑆, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗} \\ = \sum_{𝑖 \in 𝑆} (𝑧_{𝑖} \cdot \prod_{𝑗 \in 𝑆, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗}) + \sum_{𝑖 \in 𝑆} (\sum_{𝑚 \in 𝑆} 𝑔_{𝑚} (𝑖) \cdot \prod_{𝑗 \in 𝑆, 𝑗 \neq 𝑖} \frac{ℓ - 𝑗}{𝑖 - 𝑗}) \\ = 𝑧_{ℓ} + \underset{= 0}{\underset{⏟}{\sum_{𝑚 \in 𝑆} 𝑔_{𝑚} (ℓ)}} \\ = 𝑧_{ℓ} \end{aligned}

Note that we could try to add multiple roots: $(𝑥 - ℓ_{1}) (𝑥 - ℓ_{2}) \cdot 𝑔_{𝑖} (𝑥)$ , but then all the new shareholders would have access to the new shares.

You could also apply the same verifying scheme as before to this method.

We have a problem

When recovering the secret, we need to trust a single recoverer to do so and all send him all of our shares. But what if we all wanted to recover the secret at the same time?

One may naively try to implement a simple broadcast or pairwise exchange protocol, but if a single malicious actor $𝑃_{𝑚}$ wanted to prevent the others from also recovering the secret, he could just wait for everyone to send their share, and never send his. He will have all the shares needed, while the others can’t do anything.

If everyone distrusts each other, we will have this strange situation where no one wants to send their share first. One may prove that they own a valid share with a Zero-Knowledge Proof (ZKP), but will never be able to prove that he’s actually going to send it to the others.

One “solution” to this problem (not the best though) is to set a pre-defined order in which shareholders need to reveal their shares, after which it is verified each time by the others. If the share is invalid or the bearer fails to send it within a given time, the others can post a complaint against this user and abort the process.

[!WARNING] All the methods I describe below are purely experimental, and I have no idea if they are actually secure or not. If you have any feedback, please let me know!

Commitments-based ordering

After each shareholder has shared his commitment $𝐶_{𝑖} = 𝑦_{𝑖} \cdot 𝐺$ and it has been verified by everyone else, the order of reveal is defined by the value of each commitment. Let’s recall our commitments for $𝑓 (𝑥) = 𝑎_{0} + 𝑎_{1} 𝑥 + \dots + 𝑎_{𝑘 - 1} 𝑥^{𝑘 - 1}$ :

𝐶 = {𝜙_{0}, 𝜙_{1}, \dots, 𝜙_{𝑘 - 1}} | 𝜙_{𝑖} = 𝑎_{𝑖} \cdot 𝐺

One cannot manipulate the value of $𝑦_{𝑖} \cdot 𝐺$ as it is verifiable by the others with

𝑦_{𝑖} \cdot 𝐺 = \sum_{𝑖 = 0}^{𝑘 - 1} 𝜙_{𝑖}

The probability of a malicious actor being placed last in the queue and thus fool everyone is $\frac{1}{𝑘}$ for $𝑘$ recoverers if we suppose that $𝑦_{𝑖} \cdot 𝐺$ is pseudorandom. Not that good.

Incremental recovery

Let’s instead require each bearer to first send their share to everyone placed before them in the pre-defined order.

A figure is shown on the site.

We have a single shared state $𝑅$ that needs to be kept up-to-date for everyone at each round. This is to keep track of who has and who hasn’t sent their share yet. The state $𝑆$ consisting of every sent share does not need to be shared as everyone can keep track of the broadcasts to $𝑅$ received.

This way, a single malicious shareholder cannot dupe the rest of the group. But what if two malicious actors $𝑃_{𝑚}$ and $𝑃_{𝑚^{'}}$ tried hijacking the recovery ?

$𝑃_{1}$ initiates $𝑆 = {𝑦_{1}}, 𝑅 = {𝑃_{1}}$
$𝑃_{2}$ sends $𝑦_{2}$ to $𝑅$ , and gets accepted: $𝑆 = {𝑦_{1}, 𝑦_{2}}, 𝑅 = {𝑃_{1}}$
$𝑃_{𝑚}$ joins normally as well, he gets access to $𝑆$
$𝑃_{3}$ joins, and so on for other $𝑃_{𝑖}$
$𝑃_{𝑚^{'}}$ only sends his share to $𝑃_{𝑚}$ , which sends him $𝑆$ back (or not)

In this case, $𝑃_{𝑚}$ (and $𝑃_{𝑚^{'}}$ ) are the only ones able to recover the secret. This isn’t of any good either…

Inception, again

To prevent a single actor from hijacking the recovery, we will leverage once again an Inception-like scheme. Here, our new scheme will be $2$ -out-of- $𝑘$ .

Each shareholder $𝑖 \in 𝑅$ generates a random polynomial $𝑔_{𝑖} (𝑥) = 𝑧_{𝑖} + 𝑏_{𝑖, 1} 𝑥$ of degree $1$ , where $𝑧_{𝑖}$ is their respective share.

The commitment and sharing phase of $𝑔_{𝑖} (𝑗) | 𝑖, 𝑗 \in 𝑅$ continues as usual, and before recovering the secret, two shareholders $𝑃_{𝑚}$ and $𝑃_{𝑚^{'}}$ are chosen to reveal their shares. This way, when $𝑃_{𝑚}$ broadcasts his shares $𝑔_{𝑖} (𝑚) | 𝑖 \in 𝑅$ , everyone is instantly able to recover the secret.

The last step is to verify that $𝑃_{𝑚^{'}}$ also sends his shares to $𝑃_{𝑚}$ . If he does not, every other shareholder can post a complaint against him and optionally send his shares to $𝑃_{𝑚}$ , who can then recover the secret.

We now have a pretty good guarantee that the secret will be recovered by everyone, except if that very person was being explicitly targeted by the whole recovery group ( $𝑘 - 1$ people). Please also note that this method doesn’t work really well with a small number of shareholders, e.g. 3:

$𝑃_{1}$ and $𝑃_{2}$ are chosen to reveal their intermediate shares, but $𝑃_{2}$ and $𝑃_{3}$ are malicious.

Each shareholder $𝑖 \in 𝑅 = {1, 2, 3}$ splits his share $𝑧_{𝑖}$ into $𝑔_{𝑖} (𝑥) = 𝑧_{𝑖} + 𝑏_{𝑖, 1} 𝑥$ and sends $𝑔_{𝑖} (𝑗) | 𝑖, 𝑗 \in 𝑅$ to everyone.
$𝑃_{1}$ reveals his shares as expected, but $𝑃_{2}$ and $𝑃_{3}$ do not.
$𝑃_{2}$ and $𝑃_{3}$ are the only ones able to recover the secret, and $𝑃_{1}$ is left out.

References and Suggested readings

Issuing New Shamir Secret Shares Using Multi-Party Computation conduition.io
Novel Secret Sharing and Commitment Schemes for Cryptographic Applications Mehrdad Nojoumian dspacemainprd01.lib.uwaterloo.ca [PDF]
A Share-Correctable Protocol for the Shamir Threshold Scheme and Its Application to Participant Enrollment Raylin Tso, Ying Miao, Takeshi Okamoto and Eiji Okamoto citeseerx.ist.psu.edu [PDF]
Feldman’s Verifiable Secret Sharing for a Dishonest Majority Yi-Hsiu Chen and Yehuda Lindell eprint.iacr.org [PDF]
Adaptively Secure Feldman VSS and Applications to Universally-Composable Threshold Cryptography Masayuki Abe and Serge Fehr eprint.iacr.org [PDF]

Oh, so you want to work at Traefik?

2024-11-12T00:00:00.000Z

[!WARNING] If you are using this article to solve the challenge, please make sure to not just copy-paste the commands, but to understand what they do.

My goal is to allow you to learn something new, not to give you the solution on a silver platter wink

Introduction

When looking for an alternative to HAProxy or Nginx, I came across Traefik, a modern HTTP reverse proxy and load balancer made to deploy microservices with ease, even featuring Kubernetes Ingress support, or Let’s Encrypt integration.

By digging a little more on their website, I found a developer job application form. I was surprised to see that there was no traditional CV to send, but a docker command to run.

The challenge

Spun up the image as requested, I was greeted with a nice error message:

docker run -it traefik/jobs

Helmsman, where are you? (・・?)

I immediately thought of Helm, the package manager for Kubernetes, so I went ahead and started a minikube cluster.

minikube start --kubernetes-version=v1.19

Note: I used the v1.19 version of Kubernetes because it was the latest available at the time of the last update of the Docker image. (see the version list)

And then started a pod with the image.

kubectl run traefik-jobs -it --image=traefik/jobs --restart=Never

Still getting an error message, but this time it was different:

It seems I do need more permissions... May I be promoted cluster-admin? (>人<)
Hmmmm, it seems Helmsman deployment has an issue ( ˘︹˘ )

I was now sure that I was on the right track.

The image was kindly asking us to give it more permissions, so I naturally gave it the cluster-admin role. (I know, I know, it’s not a good practice, but it’s just for a CTF, right?)

# service-account.yml

---
apiVersion: v1
kind: ServiceAccount
metadata:
    name: traefik-jobs
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    name: traefik-jobs-admin
subjects:
    - kind: ServiceAccount
      name: traefik-jobs
      namespace: default
roleRef:
    kind: ClusterRole
    name: cluster-admin
    apiGroup: rbac.authorization.k8s.io

Applying the created manifest.

kubectl apply -f service-account.yml

We now have a service account with the cluster-admin role, so let’s set it to the pod.

# pod.yml

---
apiVersion: apps/v1
kind: Deployment
metadata:
    name: jobs
    labels:
        app: jobs
spec:
    selector:
        matchLabels:
            app: jobs
    template:
        metadata:
            labels:
                app: jobs
        spec:
            serviceAccount: traefik-jobs
            serviceAccountName: traefik-jobs
            containers:
                - name: jobs
                  image: traefik/jobs

kubectl apply -f pod.yml

We have a pod running with the cluster-admin role, so we should be able to take a look at the logs.

kubectl logs deployments/jobs

Look at me by the 8888 ingress [⌐■-■]

Setting up an ingress on port 8888 should do the trick.

# ingress.yml

---
apiVersion: v1
kind: Service
metadata:
    name: jobs
spec:
    selector:
        app: jobs
    ports:
        - protocol: TCP
          port: 8888
          targetPort: 8888
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
    name: jobs
spec:
    rules:
        - http:
              paths:
                  - path: /
                    pathType: Prefix
                    backend:
                        service:
                            name: jobs
                            port:
                                number: 8888

kubectl apply -f ingress.yml

And restarting the pod.

kubectl rollout restart deployment jobs

The logs now say:

You have set up your cluster in good taste (・ω<)
Now that you have set up an ingress... You should be able find me...

It should now be as simple as port-forwarding the ingress to our local machine.

kubectl port-forward deployments/jobs 8888:8888

And then, we can access the pod on localhost:8888.

Come on, use that damn ingress please (°▽°;)

I see what you did there, Traefik.

As Traefik provides an ingress controller for Kubernetes, I think it’s safe to assume that they want us to use it.

Well, well, well… Let’s create a Traefik Proxy. I followed the quick-start guide from the documentation.

Various resources are created:

# traefik/00-role.yml

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
    name: traefik-role

rules:
    - apiGroups:
          - ""
      resources:
          - services
          - endpoints
          - secrets
      verbs:
          - get
          - list
          - watch
    - apiGroups:
          - extensions
          - networking.k8s.io
      resources:
          - ingresses
          - ingressclasses
      verbs:
          - get
          - list
          - watch
    - apiGroups:
          - extensions
          - networking.k8s.io
      resources:
          - ingresses/status
      verbs:
          - update

# traefik/00-account.yml

apiVersion: v1
kind: ServiceAccount
metadata:
    name: traefik-account

# traefik/01-role-binding.yml

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
    name: traefik-role-binding

roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: traefik-role
subjects:
    - kind: ServiceAccount
      name: traefik-account
      namespace: default

The Traefik deployment itself:

# traefik/02-traefik.yml

kind: Deployment
apiVersion: apps/v1
metadata:
    name: traefik-deployment
    labels:
        app: traefik

spec:
    replicas: 1
    selector:
        matchLabels:
            app: traefik
    template:
        metadata:
            labels:
                app: traefik
        spec:
            serviceAccountName: traefik-account
            containers:
                - name: traefik
                  image: traefik:v2.10
                  args:
                      - --api.insecure
                      - --providers.kubernetesingress
                  ports:
                      - name: web
                        containerPort: 80
                      - name: dashboard
                        containerPort: 8080

And finally, the service:

# traefik/02-traefik-services.yml

apiVersion: v1
kind: Service
metadata:
    name: traefik-dashboard-service

spec:
    type: LoadBalancer
    ports:
        - port: 8080
          targetPort: dashboard
    selector:
        app: traefik
---
apiVersion: v1
kind: Service
metadata:
    name: traefik-web-service

spec:
    type: LoadBalancer
    ports:
        - targetPort: web
          port: 80
    selector:
        app: traefik

Applying the manifests.

kubectl apply -f 00-role.yml \
              -f 00-account.yml \
              -f 01-role-binding.yml \
              -f 02-traefik.yml \
              -f 02-traefik-services.yml

We now have a Traefik proxy running on our cluster, and as Traefik relies on ingress resources, our pod should be directly accessible via the proxy.

kubectl port-forward deployments/traefik-deployment 8080:8080

The HTTP Service for our pod is effectively listed in the dashboard:

Forwarding the proxy port to something fancy:

kubectl port-forward deployments/traefik-deployment 1337:80

Visiting localhost:1337:

I have to tell you something...
Something that nobody should know.
However, everyone could see it.
It's even part of my public image.
Come back when you know more.
But remember, it's a secret (ᵔᴥᵔ)

The message is a bit cryptic, but it seems that we have to find something in the image.

Running docker inspect on the image, we get a ton of information:

docker inspect traefik/jobs

{
    "Id": "sha256:...",
    "RepoTags": ["traefik/jobs:latest"],
    "Comment": "buildkit.dockerfile.v0",
    "Created": "2020-10-22T13:50:23.922043068Z",
    "Config": {
        // ...
        "WorkingDir": "/",
        "Entrypoint": ["/start"],
        "Labels": {
            "helmsman": "dcc9c530767c102764d45d621fc92317"
        }
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Size": 27754496,
    "VirtualSize": 27754496
    // ...
}

And look at that, there is a helmsman label with a value.

"Labels": {
    "helmsman": "dcc9c530767c102764d45d621fc92317"
}

This looked juicy, so I first tried to decode the value as hex, but the output was… weird.

echo dcc9c530767c102764d45d621fc92317 | xxd -r -p

���0v|'d�]b�#%

Base64 wasn’t any better.

echo dcc9c530767c102764d45d621fc92317 | base64 -d

u�=s�����M��x�޶��=�}{%

Sorry, I don’t speak Minecraft enchantment table…

I then remembered the end of the message:

But remember, it’s a secret shushing

It is just a secret, so there is no need to decode it, we just have to set it as some kind of header or maybe an environment variable. Setting various headers on the HTTP requests didn’t do anything, so I looked up on the Internet how to set env. variables on containers. After a few minutes, I was feeling that I was going nowhere, so I continued looking for other ways to provide the secret to the pod.

And guess what, the answer was simply to literally set the secret as… a secret.

This can be done with the kubectl create secret command.

kubectl create secret generic helmsman --from-literal=helmsman=dcc9c530767c102764d45d621fc92317

Restarting the pod, port-forwarding the proxy, and visiting localhost:1337 again, we now get a nice form to fill and submit.

Conclusion

This was a fun challenge, and I learned a lot about Kubernetes and Traefik in the process. I hope you enjoyed reading this article as much as I enjoyed solving this CTF grinning

In the end, I learned how to use Traefik, which proved to be an amazing alternative to Apache or Nginx. It’s really easy to set up, and the fact that it can automatically discover services and create routes for them is really cool. I am definitely going to use this in future projects.

petal

Sunflowers have math in them, wtf?

The dumb rule

The golden angle

Placing the seeds

CTFs are dead

LLMs killed my will to do stuff

No Ads, No Algorithms, No Problem

Return to Roots

How to Use RSS

As a Reader

As a Publisher

Atom ? RSS ?

Start using it!!!

SquarePants Sponge Hashing

Adaptor Signatures FtW

Atomic Swaps

Nullifying Adaptor Signatures

Private Key Exposure Threat

Secret Sharing + Adaptor Signatures = ?

References and Suggested readings

Elliptic Curves for Sane People

Working with finite fields

References and Suggested readings

Lagrange Interpolation Primer

Polynomials

Lagrange Interpolation

Using ECC for (Multi-)Signatures

ECDSA Signatures

Cool Kids Public Key Recovery

Schnorr Signatures

Why it Works

Aggregating Signatures

But wait!

Multi-Signatures, don’t trust, verify

There’s more!

References and Suggested readings

Shamir Secret Sharing in a Nutshell

Splitting the Secret

Reconstructing the Secret

Commitments, Proofs and Verifications

Verifying that 𝑓(0) is a private key

Pedersen’s Verifiable Secret Sharing (PVSS)

Bob just got hit by a bus, what now?

Inception

Verifiable Inception

Single share issuing

We have a problem

Commitments-based ordering

Incremental recovery

Inception, again

References and Suggested readings

Oh, so you want to work at Traefik?

Introduction

The challenge

Conclusion

Verifying that $𝑓 (0)$ is a private key