diff --git a/config.toml b/config.toml
index 89d02a1..0b7f46a 100644
--- a/config.toml
+++ b/config.toml
@@ -1,4 +1,76 @@
-baseURL = "https://blog.jaseg.de/"
+baseURL = "http://jaseg.de/"
languageCode = "en-us"
-title = "jaseg.de"
-theme = "hugo-classic"
+title = "Home"
+copyright = "Jan Sebastian Götte"
+theme = "conspiracy"
+enableRobotsTXT = true
+
+[outputs]
+home = ['html', 'rss']
+taxonomy = ['html', 'rss']
+
+[params]
+fediverse_account = "@jaseg@chaos.social"
+
+[taxonomies]
+category = "Categories"
+blog = "Posts"
+
+[[menu.main]]
+name = "Home"
+url = "/"
+weight = 1
+
+[[menu.main]]
+name = "Blog"
+url = "/blog/"
+weight = 2
+
+[[menu.main]]
+name = "Projects"
+url = "/projects/"
+weight = 3
+
+[[menu.main]]
+name = "About"
+url = "/about/"
+weight = 4
+
+[[params.profile_links]]
+name = "cgit"
+url = "https://git.jaseg.de/"
+weight = 1
+
+[[params.profile_links]]
+name = "Github"
+url = "https://github.com/jaseg"
+weight = 2
+
+[[params.profile_links]]
+name = "Gitlab"
+url = "https://gitlab.com/neinseg"
+weight = 3
+
+[[params.profile_links]]
+name = "Mastodon"
+url = "https://chaos.social/@jaseg"
+weight = 4
+
+[[params.footer_links]]
+name = "About"
+url = "/about/"
+weight = 1
+
+[[params.footer_links]]
+name = "Imprint"
+url = "/imprint/"
+weight = 2
+
+[[params.homepage_categories]]
+title = "Blog"
+key = "blog"
+weight = 2
+count = 10
+
+[security.exec]
+allow = ["^dart-sass-embedded$", "^go$", "^npx$", "^postcss$", "^rst2html$"]
diff --git a/content/_index.rst b/content/_index.rst
new file mode 100644
index 0000000..ad39a14
--- /dev/null
+++ b/content/_index.rst
@@ -0,0 +1,9 @@
+---
+title: jaseg.de
+---
+
+Hi there, and welcome to my personal website.
+
+I'm jaseg, and I write about my projects here. You can find long-form articles in the blog, and links to my open-source
+projects on the projects page. On the top right of this page, there are links to my git repositories and social media
+pages. If you want to learn more about me, head over to the about page.
diff --git a/content/about.rst b/content/about.rst
deleted file mode 100644
index 6d6fc54..0000000
--- a/content/about.rst
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: "About jaseg"
----
-
-About
------
-
diff --git a/content/about/index.rst b/content/about/index.rst
new file mode 100644
index 0000000..2acfee5
--- /dev/null
+++ b/content/about/index.rst
@@ -0,0 +1,65 @@
+---
+title: "About jaseg"
+---
+
+About
+-----
+
+Hej, I'm Jan, or jaseg. At the moment I'm doing a PhD (Dr.-Ing.) at TU Darmstadt in Computer Science, specializing on
+Hardware Security. This is my personal website where I publish things that I find interesting.
+
+I self-host my code at `git.jaseg.de `__, but I am also on `github `__
+and on `gitlab `__. I use github for issue tracking for some of my projects such as
+`gerbolyze `__ and `python-mpv `__. I maintain
+the `python-mpv `__ and `gerbolyze `__ python
+packages on PyPI. Release tags on these two repositories are signed with the release signing key found `on github
+`__ and below.
+
+I am not on any social network, but feel free to write me an email at `hello@jaseg.de
+`__.
+
+I do not use application-level email encryption such as S/MIME or PGP. If you need a higher level of secrecy than
+regular old email provides, please ask around for my signal contact or email me a file encrypted using `age
+`__ with one of the SSH keys listed `on my github
+`__. You can find both PGP and other SSH keys that I have used in the past on the
+internet, but please consider these keys revoked, and do not use them to encrypt anything you send me.
+
+Python package release signing key
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+I use this GPG key (key ID ``ED7A208EEEC76F2D``) to sign git release tags of both `gerbolyze `__ and `python-mpv
+`__:
+
+.. code::
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+ mDMEXom49xYJKwYBBAHaRw8BAQdA/KrWMt2MKGIZUvlQZnWjNd6i8/ZYjRsBQqEf
+ PJ8pJ+20NHB5dGhvbi1tcHYgUmVsZWFzZSBTaWduaW5nIEtleSA8cHl0aG9uLW1w
+ dkBqYXNlZy5kZT6IlgQTFggAPhYhBONvdTB/Cg7C0UX/XO16II7ux28tBQJeibj3
+ AhsDBQkSzAMABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO16II7ux28thRYA
+ /3Yl1RdeUGor6K0RTxce9TIBB+DpLNupJgB9f6onuocpAQC614zQ/RQ6rkGTHCwA
+ ElFClWRQ5eppj0jpAuH15udqAbg4BF6JuPcSCisGAQQBl1UBBQEBB0A0mrXSv6rj
+ ajCmZR4H4OtowAx477YS+yWARqo1NtdgJwMBCAeIfgQYFggAJhYhBONvdTB/Cg7C
+ 0UX/XO16II7ux28tBQJeibj3AhsMBQkSzAMAAAoJEO16II7ux28tMZwBAIUpHHvP
+ gRW2jQuzdw1r06kItfFk/0t+mgNUQ2+vtbhzAP98BoWx7lv+bvlIbBaVgLldusj0
+ pHnZI/0y3ksMBkdbBw==
+ =Mr6G
+ -----END PGP PUBLIC KEY BLOCK-----
+
+About this site
+---------------
+
+This site is made with the hugo static site generator. I made the theme myself, feel free to grab a copy at
+`git.jaseg.de `__. The nifty auto-reflowing code embeds are
+made with some CSS magic I made that you can find in `style.css
+`__.
+The body text is typeset in Roboto Slab, created by `Christian Robertson `__ while
+working at Google. The headlines are set in Nyght Serif, a font by `Maksym Kobuzan `__.
+Check out their other fonts, their work is beautiful! Source code is typeset in Fira Code, a derivate by ... from
+Mozilla's `Fira Mono `__ font, designed by `Erik Spiekermann
+`__, `Ralph du Carrois `__, `Anja Meiners
+`__ and Botio Nikoltchev of Carrois Type Design, now succeeded by `bBoxType
+`__ , and Patryk Adamczyk of Mozilla. The photo of mountains
+that's used in the background of this site is by `Fabrizio Conti `__ and can be found on
+`Unsplash `__.
+
diff --git a/content/blog/8seg/8seg-digit-circuit.png b/content/blog/8seg/8seg-digit-circuit.png
new file mode 100644
index 0000000..001c896
Binary files /dev/null and b/content/blog/8seg/8seg-digit-circuit.png differ
diff --git a/content/blog/8seg/index.rst b/content/blog/8seg/index.rst
new file mode 100644
index 0000000..6b8d676
--- /dev/null
+++ b/content/blog/8seg/index.rst
@@ -0,0 +1,203 @@
+---
+title: "8seg Technical Overview"
+date: 2023-12-26T15:26:00+01:00
+summary: >
+ 8seg is a large-scale LED light art installation that displays text on a 1.5 meter high, 30 meter wide
+ 8-segment display made from cheap LED tape.
+---
+
+Prologue
+--------
+
+German hacker culture has this intense love for things that light up in colorful ways. Like for many others in this
+community, I have always been fascinated by LEDs. One of the first things on my pile of unfinished projects was to build
+my own LED matrix and use it to display text. When I started that project, I was still new to electronics. Back then,
+commercial LED matrices were limited to red or green color only, and were very expensive, so there was an incentive to
+build your own. At the same time, while individual LEDs were'nt expensive anymore, they hadn't started to be cheap yet,
+either. On top of the material cost, back then there were no PCB fabs, and especially no PCB assembly houses that a
+hobbyist could afford. Ultimately, I ended up never finishing this project because I felt it was more of a feat of
+material wealth than of technical prowess.
+
+Over time, LEDs came down in price, and peoople started using them in all sorts of fun things. Around the mid-2010s,
+cheap-ish, ready-made tapes and chains of RGB LEDs that included WS2811 or similar digitally controllable driver chips
+led to a cambrian explosion in projects involving large amounds of colorful LEDs since suddenly, all you needed was an
+arduino and a beefy power supply to individually control an almost unlimited number of these LEDs.
+
+Today, LED technology has advanced even furhter, to a point where now you can buy staggering quantities of the second
+generation of these controllable LEDs that provides better color rendering embedded in all sorts of shapes, from tapes
+through rings to grids. When I built the first matelight_ in 2013, the matelight's 640 individually-controllable LEDs
+were *a lot*. Today, you can buy a roll with several thousand channels for about the price of a nice pizza.
+
+The idea behind 8seg
+--------------------
+
+Living through this amazing escalation of LED technology, in 2018, I looked at a then-obsolete piece of single-color,
+dumb, non-controllable LED tape with a simple question in mind: Taking this unsophisticated artifact of yesterday's
+technology, what would be the coolest thing I could build from it? Can I buld something that not only rivals, but
+outmatches the modern controllable LED stuff? From that question, I set myself two goals. First, I wanted to keep the
+project's use of financial and labor resources reasonable. A lot of art consists of taking a simple idea, and simply
+extrapolating its implementation to a ridiculous scale at the expense of the artist's time and wallet. That wasn't the
+point I wanted to make. I wanted to make something cool from an obsolete technology, not prove how much patience I had
+soldering. My second goal was to create something that is meaningfully controllable. Controllability is much harder with
+these dumb LED tapes, but it is possible nontheless, and I wanted to test out how far you could go with it.
+
+After thinking through a number of possibilities, I settled on the basics of the 8seg design I ended up realizing. The
+installation would be a banner-style display consisting of a series of characters made from non-controllable LED tape.
+The banner can be rigged up in any convenient air space, bending and folding to conform to the space's shape and size.
+The key idea behind 8seg is that it makes up for it's lack of control fidelity with sheer size. If nothing else, this
+non-controllable LED tape is *cheap*.
+
+The design of a single 8seg character
+-------------------------------------
+
+Each 8seg character consists of 8 *segments* of LED tape that are inter-connected through small circuit boards, four in
+the corners, and one in the center. As it turns out, 8 segments arranged in this shape are enough to display all of the
+English language's alphabet as well as numbers in a weird, but readable form.
+
+The electrical design of an 8seg character has one weird trick at its core. To avoid having to run a bunch of wires from
+some kind of driver circuit board to each of the eight segments, I thought, why not use the LED tape itself instead for
+power and data transmission? Wires are heavy, expensive, and annoying to solder, so if I could find a way to
+interconnect the LED tape so that it can all be driven from a driver circuit located at one of the character's
+junctions while simultaneously powering that driver circuit, an 8seg character wouldn't need any wires at all anymore.
+
+8seg achieves this feat using a circuit as shown in the diagram below. Interconnections between the LED tape segments
+are done with a small circuit board in each of the four corners. The design is rotationally symmetric, and all four of
+these boards are identicaly. The top right and bottom left corners simply use the back side of the same circuit board
+used in the top left and bottom right corners.
+
+.. image:: 8seg-digit-circuit.png
+
+The driver circuit sits at the center of the character and directly connects to the four diagonal segments. The key
+thought behind 8seg's driving scheme is that there are two common phases wound through the display in a zig-zag pattern
+as shown in red and blue in the schema below. These phases alternate their polarity at a high frequency. Each segment
+has its negative pole connected to one of these two phases, and can be turned on by the driver while that phase is low
+and the other phase is high. While a phase is high, the LEDs on all segments connected to that phase are reverse-biased,
+and thus these segments remain dark.
+
+The positive poles of all segments are connected to the driver circuit in the center through a spiral pattern. Each arm
+of the spiral is made up of two segments, one diagonal on the inside, and one horizontal or vertical on the outside.
+The two segments on each spiral arm are on different phases, one on each of the two phases. Thus, during a single cycle
+of the two phases alternating polarity, first one of the two segments has its polarity the right way around, then the
+other. The driver can turn on the active segment by connecting the spiral control line to the positive LED supply
+voltage.
+
+Both phases cross at the center where the driver circuit is located, so the driver can power itself from the two phases
+using a simple full bridge rectifier.
+
+Saving copper with point of load regulation
+-------------------------------------------
+
+In the beginning, I experimented with the design above, putting 12V AC on the two phases, and letting the driver switch
+its derived LED supply using some cheap MOSFETs. This simple design totally works, but it has an important shortcoming.
+
+8seg is designed to be physically *very* large. This means that not only does it have a large number of LEDs that
+together need a lot of current, it also has to transmit all of that current across significant physical distances. The
+consequence of this was that in the initial design, I was looking at either needing hundreds of Euros worth of copper
+cables, or burning hundreds of Watts of electricity into heat if I were to use thinner cables. In this case, cables act
+like resistors. In a resistor, power dissipation rises with the square of the current inside the cable. This is bad for
+8seg since it means halving the amount of copper in those wires increases power dissipation in these wires fourfold.
+
+Despite that downside, this square law does come with an upside, too. If we assume we have wires of a particular fixed
+diameter, if we can halve the current through those wires, we can quarter the wires' power dissipation. If we want to
+deliver the same amount of power to the LEDs as before, to halve wire current, we have to double the voltage, and add
+some circuitry on the drivers to convert that increased voltage back down to close to our LED tape's nominal 12V.
+
+Alas, simply doubling the voltage leads to one question: How is it that we can pass double the voltage through our LED
+tape to the center control circuit? Isn't the LED tape made for 12V operation only, not 24V? The answer to this
+apparent problem is that the center is connected to the AC bus voltage only through the negative side of the LED tapes,
+and controls their positive sides to turn them on or off. The AC bus voltage never appears directly across any single of
+the eight segments. At the same time, a simple buck converter stepping down our new 24V bus voltage to 12V, and feeding
+the segment control transistors with that instead of feeding them straight from the rectified AC bus allows us to feed
+the segments with 12V. The only difference between this circuit and the straight 12V variant is that now, during OFF
+times, the LED tapes see a negative 24 v across them. To make sure that's not a problem, I tested a number of them with
+different LED colors and from different manufacturers, and all of them held up past the 50 V I could easily generate
+with my lab power supply.
+
+Synchronous rectification
+-------------------------
+
+I implemented the point-of-load regulation in a new revision of the center circuit, and built a prototype digit. When I
+tested this prototype, to my dismay, I noticed some really strange behavior. In my tests, the LED tape did not properly
+light up, and when I checked the voltages with my oscilloscope, I noticed that the center circuit's ground was floating
+several volts *below* the AC bus voltage's negative phase. How come?
+
+After some head-scratching, I found that this problem was due to a simple instance of Kirchhoff's current law. Consider
+the point where the AC bus voltage's currently negative phase enters the center circuit board. Let's say that we
+dissipate 24 Watts in the segments' LEDs. In this case, at 24 Volts, 1 Ampère will flow into the center circuit's
+terminal connected to the currently positive phase, and out from the center circuit's terminal connected to the
+currently negative phase.
+
+Now consider the current through the LED tape. During one half-cycle of the AC bus, the center circuit can only address
+the four segments that have their negative rail connected to the currently negative phase of the AC bus. If one of these
+four segments is currently on and dissipating our 24 Watts, that segment will be fed 2 Ampère of current from the center
+circuit through its positive rail. My mistake was that I did not consider what happened to the return current here.
+The corresponding 2 Ampère return current of course flows back through the segment's negative rail into the center
+circuit, and herein lies the issue: That negative rail is where our center circuit's supply current comes from! This
+means that according to Kirchhoff's current law, the 1 A flowing out from the center circuit at its input are adding up
+with the 2 A flowing into it. The result of this is that in the currently positive phase's connection, we get 1 A
+flowing into the center circuit, while in the negative phase connection, we get (-1) + (+2) resulting in another 1 A
+flowing into it! The only terminal where current flows *out* of the center circuit is the positive terminal connected to
+the active segment, out of which 2 A of current are flowing.
+
+The big problem with this confusing scenario is that this means the bridge recitifier in our center circuit cannot work,
+since its negative-side diodes are reverse biased while any of the segments are on. We can't just add more diodes here,
+since that would just short both AC bus rails together. Instead, the solution is to add one rather chonky MOSFET in
+parallel with each of the two negative-side diodes of the bridge rectifier that are controlled by the center circuit to
+act as a sort of synchronous rectifier. When we turn on one of the segments, we have to turn on the MOSFET on the
+currently negative rail to allow the segment's return current to bypass the bridge rectifier's negative-side diode. Fun
+fact: If we turn on the wrong MOSFET out of the pair, we short the AC bus, resulting in a very quick end of life for that
+poor MOSFET.
+
+Power line data communication
+-----------------------------
+
+As we saw above, the driver providing power to a string of digits has to continuously alternate the polarity of its
+output voltage to provide one part of the digit circuits' multiplexing. Since we want to provide the control information
+to the center circuits through those same two wires, we can choose between a number of viable power line communication
+schemes. These schemes usually require a beefy transmitter adding a modulation at a frequency much larger than the
+underlying bus frequency, and a filter circuit at each receiver to filter that signal from the much stronger fundamental
+AC waveform. In our application, I saw two issues with these classical approaches. First, they require fairly complex
+circuitry, especially the beefy transmitter at the driver. Second, they are susceptible to attenuation with either
+changing load or over long distances, which could potentially be a problem with the high currents and long(ish) wiring
+runs 8seg needs.
+
+Because of these disadvantages, I decided on another approach entirely. Instead of modulating our control signal on top
+of the AC power waveform, we modulate our control data *into* the AC power waveform. To not interfere with the display
+and cause outages or flicker, and to avoid having to blank the display during transmissions, we choose a modulating
+technique that leaves the proportions of negative and positive half-waves undisturbed. The practical realization of this
+is that instead of alternating positive and negative half-waves, we send a positive half wave for each "one" bit, and a
+negative half wave for each "zero" bit, effectively creating a phase shift keyed signal with two states with an
+180-degree phase shift, with the transmitted bit rate synchronized to twice the underlying carrier frequency.
+
+The remaining question is how one can encode arbitrary binary data into a continuous stream of ones and zeros that is
+precisely 50 % ones and 50 % zeros across any time span longer than a few dozen bits. There exists a near-optimal
+solution to this question from ethernet over copper twisted pairs. In ethernet, the encoded and modulated signal passes
+through an isolation transformer to protect the ethernet transceiver from interference or dangerous voltages coming in
+through the ethernet port. For this isolation transformer to work, the modulated ethernet signal must be exactly
+balanced to avoid saturating the transformer's core with a DC offset. Ethernet solves this issue by using an encoding
+known as `8b/10b encoding`_. 8b/10b encoding is named like that because it specifies a way to produce a 10 bit codeword
+from any 8 bit input data word while guaranteeing that the resulting codewords are always precisely balanced when
+looking at two or more consecutively.
+
+Framing
+-------
+
+Since 8b/10b encoding maps a space of 256 data words to 1024 code words, there necessarily are a number of unused code
+words. While for some of them, leaving them unallocated is beneficial because it improves error tolerance by decreasing
+the probability of one code word turning into another undetectably when a single one of its bits is flipped, even
+accounting for that it leaves some room for other uses. In 8b/10b, these leftover code words are used for synchronizing
+the receiver to the transmitter, and for framing transmissions. Synchronization is necessary for the receiver to know
+where a code word stards, and 8b/10b has a handful of special "comma" code words that can be uniquely identified in a
+continuous stream of received ones and zeros, because no other combination of 8b/10b code words could produce the same
+sequence of ones and zeros of the comma code word anywhere.
+
+The leftover code words that are not commas are useful, too. They can be used, for instance, as filler code words
+betwene actual data transmissions, or to act as framing markers denoting things like the end of a protocol message.
+
+The 8seg driver produces its modulation waveform by translating all data to be transmitted into 8b/10b codes, padding
+the result with framing markers and filler codes, and copy-pasting together the corresponding AC waveform from a small
+set of pre-programmed waveform transitions.
+
+.. _matelight: https://github.com/jaseg/matelight
+.. _`8b/10b encoding`: https://en.wikipedia.org/wiki/8b/10b_encoding
+
diff --git a/content/blog/_index.rst b/content/blog/_index.rst
new file mode 100644
index 0000000..9bff67d
--- /dev/null
+++ b/content/blog/_index.rst
@@ -0,0 +1,3 @@
+---
+title: Blog
+---
diff --git a/content/blog/ashen-yanartas/ashen-logo-text-dark-plain.svg b/content/blog/ashen-yanartas/ashen-logo-text-dark-plain.svg
new file mode 100644
index 0000000..4ed3c9c
--- /dev/null
+++ b/content/blog/ashen-yanartas/ashen-logo-text-dark-plain.svg
@@ -0,0 +1,37 @@
+
+
+
+
diff --git a/content/blog/ashen-yanartas/ashen-logo-text-light-plain.svg b/content/blog/ashen-yanartas/ashen-logo-text-light-plain.svg
new file mode 100644
index 0000000..f3e7460
--- /dev/null
+++ b/content/blog/ashen-yanartas/ashen-logo-text-light-plain.svg
@@ -0,0 +1,37 @@
+
+
+
+
diff --git a/content/blog/ashen-yanartas/index.rst b/content/blog/ashen-yanartas/index.rst
new file mode 100644
index 0000000..8c37392
--- /dev/null
+++ b/content/blog/ashen-yanartas/index.rst
@@ -0,0 +1,59 @@
+---
+title: "Project Announcement: Ashen and Yanartas"
+date: 2026-05-31T08:00:00+02:00
+summary: >
+ There are exciting things ahead for the next year: I have been granted funding by both nlnet and by prototype fund
+ for open-source work on an open source hardware Hardware Security Module. As a vessel for this project, I created a
+ consulting company, yasec.
+---
+
+I'm currently in the last days of finishing my PhD (Dr.-Ing.) in Electrical Engineering. To make sure things don't get
+boring afterwards, I've been busy looking for new opportunities. As a result, there are exciting things ahead for the
+next year: I have been granted funding by both nlnet *and* by Prototype Fund for open-source work on an Open Source
+Hardware Hardware Security Module. As infrastructure for these projects, I created a consulting company, `yasec
+`__.
+
+Prototype Fund supports Ashen, the OS for open-source HSMs
+----------------------------------------------------------
+
+.. raw:: html
+
+
+
+
+
+
+Starting June 2026, I will be working on Ashen_, an open-source software stack that provides the operating system layer
+for open-source HSMs. The project is funded as part of `Prototype Fund`_'s Class 02.
+
+Compared to existing open-source HSM software that work at the application level and that don't
+consider physical attacks, this stack will provide the underlying operating system services to protect such systems from
+physical attacks. A key component of this stack will be a portable mechanism to connect hardware tamper sensors to a
+system. The stack will enable deterministic guarantees of the maximum latency until secrets are destroyed after a tamper
+alarm was raised.
+
+.. _Ashen: https://yasec.de/projects/ashen/
+.. _`Prototype Fund`: https://www.prototypefund.de/
+
+nlnet supports Yanartas, the OSHW HSM platform
+----------------------------------------------
+
+After work on the Ashen software stack is completed, I will continue by creating Yanartas_, an Open Source Hardware
+design for a complete open-source Hardware Security Module that provides protection against advanced physical attacks
+using a security mesh based on the `Inertial HSM`_ technology I developed during my PhD. The design will be customizable
+to different use cases and payload sizes from microcontrollers to whole servers.
+
+.. _Yanartas: https://yasec.de/projects/yanartas/
+.. _`Inertial HSM`: https://tches.iacr.org/index.php/TCHES/article/view/9290
+
+Let's talk!
+-----------
+
+In case you're interested to talk about hardware security engineering or open-source hardware, feel free to reach out
+through email or on mastodon. The projects are in an early stage, and I'm looking both for collaborators for these
+projects, and for opportunities once these projects have been completed. At this time, I only have a small amount of
+spare capacity outside of these projects, but that will change with time. I'd love to hear about *your* projects and
+your needs for specialist work in case you're interested.
+
+Follow this blog's `RSS `__ and follow me `on mastodon `__ for
+updates!
diff --git a/content/blog/ashen-yanartas/yasec-logo-v1-dark-plain.svg b/content/blog/ashen-yanartas/yasec-logo-v1-dark-plain.svg
new file mode 100644
index 0000000..ad9a0d2
--- /dev/null
+++ b/content/blog/ashen-yanartas/yasec-logo-v1-dark-plain.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/content/blog/ashen-yanartas/yasec-logo-v1-light-plain.svg b/content/blog/ashen-yanartas/yasec-logo-v1-light-plain.svg
new file mode 100644
index 0000000..1c70f81
--- /dev/null
+++ b/content/blog/ashen-yanartas/yasec-logo-v1-light-plain.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/content/blog/css-only-code-blocks/index.rst b/content/blog/css-only-code-blocks/index.rst
new file mode 100644
index 0000000..c9dc2fe
--- /dev/null
+++ b/content/blog/css-only-code-blocks/index.rst
@@ -0,0 +1,209 @@
+---
+title: "Code listings with nice line wrapping and line numbers from plain CSS"
+date: 2025-07-23T23:42:00+01:00
+summary: >
+ Code listings in web pages are often a bit of a pain to use. Usually, they don't wrap on small screens. Also,
+ copy-pasting code from a code listing often copies the line numbers along with the code. Finally, many
+ implementations use heavyweight HTML and/or javascript, making them slow to render. For this blog, I wrote a little
+ CSS hack that renders nice, wrapping code blocks with line continuation markers in plain CSS without any JS.
+---
+
+Code listings in web pages are often a bit of a pain to use. Often, they don't wrap on small screens. Also, copy-pasting
+code from a code listing often copies the line numbers along with the code. Finally, many implementations use
+heavyweight HTML and/or javascript, making them slow to render (looking at you, gitlab).
+
+For this blog, I wrote an implementation that renders HTML code listings entirely without JavaScript, renders line
+numbers using plain CSS such that they don't get selected with the code, and that works with the browser to wrap in a
+natural way while still supporting the little line continuation arrows that are used to show that a line was soft
+wrapped in text editors.
+
+This blog is rendered as a static site using Hugo_ from a pile of RestructuredText_ documents. RestructuredText renders
+code listings using Pygments_ by default. Pygments hard-bakes the line numbers into the generated HTML, so I am using a
+`monkey-patched`_ hook that changes the line number rendering to just a bunch of empty ```` elements. The resulting
+HTML for a code block then looks like this:
+
+.. code:: html
+
+
+
+
+ The code!
+
+
+
+
+You can find the (rather short) source of the ``rst2html`` wrapper `below <#rst2html-wrapper>`_.
+
+The CSS
+-------
+
+This modified HTML structure of the code listing gets accompanied by some CSS to make it flow nicely. Here is a listing
+of the complete CSS controlling the listing. The only bit that isn't included here is the actual syntax styling rules
+for the pygments tokens.
+
+.. code:: css
+
+ /*****************************************************/
+ /* Code block formatting / syntax highlighting rules */
+ /*****************************************************/
+
+ .code {
+ font-family: "Fira Code";
+ font-size: 13px;
+ text-align: left; /* Override default content "justify" alignment */
+ white-space: pre-wrap;
+ word-wrap: break-word;
+ overflow-x: auto;
+ display: grid;
+ align-items: start;
+ grid-template-columns: min-content 1fr;
+ }
+
+ .code > .line {
+ padding-left: calc(2em + 5px);
+ text-indent: -2em;
+ padding-top: 2px;
+ min-width: 15em;
+ }
+
+ /* Make individual syntax tokens wrap anywhere */
+ .code > .line > span {
+ overflow-wrap: anywhere;
+ white-space: pre-wrap;
+ }
+
+ /* We render line numbers in CSS! */
+ .code > .lineno {
+ counter-increment: lineno;
+ word-break: keep-all;
+ margin: 0;
+ padding-left: 15px;
+ padding-right: 5px;
+ overflow: clip;
+ position: relative;
+ text-align: right;
+ color: var(--c-text-muted);
+ border-right: 1px solid var(--c-fg-highlight);
+ align-self: stretch;
+ }
+
+ /* We also handle line continuation markers in CSS. */
+ .code > .lineno::after {
+ position: absolute;
+ right: 5px;
+ content: "\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳";
+ white-space: pre;
+ color: var(--c-text-muted);
+ }
+
+ /* Insert the actual line number */
+ .code > .lineno::before {
+ content: counter(lineno);
+ }
+
+ .code::before {
+ counter-reset: lineno;
+ }
+
+ .code .hll {}
+ /* Following are about 50 lines that define the styling of each kind of pygments syntax highlight token. These lines
+ all look like the following: */
+ .code .c { color: var(--c-text); font-weight: 400 } /* Comment */
+
+This CSS does a few things:
+
+ 1. It renders the ``
`` code listing element using a two-column CSS ``display: grid`` layout. The left column is
+ used for the line numbers, and the right column is used for the code lines.
+ 2. It numbers the lines using a `CSS Counter`_. CSS counters are meant for things like numbering headings and such, but
+ they are a perfect fit for our purpose.
+ 3. It inserts the counter value as the line number into the ```` element's ``::before``
+ pseudo-element. A side effect of using the ``::before`` pseudo-element is that without doing anything extra, the
+ line numbers will remain outside of the normal text selection so they will neither be highlighted when selecting
+ listing content, nor will they be copied when copy/pasting the listing content.
+ 4. It inserts a string of ``"\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳\a↳"`` into the line number span's
+ ``::after`` pseudo-element. This string evaluates to a sequence of unicode arrows separated by line breaks, and
+ starting with an empty line. The ``::after`` pseudo-element is positioned using ``position: absolute``, and the
+ parent ```` has ``position: relative`` set. This way, the arrow pseudo-element gets placed on
+ top of the lineno span without affecting the layout at all. By setting ``overflow: clip`` on the parent ````, the arrow pseudo-element gets cut off vertically wherever the parent lineno element naturally
+ ends.
+
+The line number span is inserted into the parent ``
`` element's CSS grid using ``align-self: stretch``, which
+causes it to vertically stretch to fill the available space. Since the line number span only contains the line number,
+its minimum height is a single line. As a result, it will stretch higher only when the corresponding code line in the
+right grid column stretches vertically because of line wrapping. When that happens, part of the arrow pseudo-element
+starts showing through from behind the ``overflow: clip`` of the line number span, and one arrow gets rendered for each
+wrapped listing line.
+
+When the page is too narrow, we don't want the code listing's lines to wrapp into a column of single characters. To
+prevent that, we simply set a ``min-width`` on the ```` in the right column, and set ``overflow-x:
+auto`` on the listing ``
``. This results in a horizontal scroll bar appearing whenever the listing gets too narrow.
+
+You can try out the line wrapping by resizing this page!
+
+rst2html wrapper
+----------------
+
+Here is the python ``rst2html`` wrapper that monkey-patches code rendering. I made hugo invoke this while building the
+page by simply overriding the ``PATH`` environment variable.
+
+.. code:: python
+
+ #!/usr/bin/env python3
+ # Based on https://gist.github.com/mastbaum/2655700 for the basic plugin scaffolding
+
+ import sys
+ import re
+
+ import docutils.core
+ from docutils.transforms import Transform
+ from docutils.nodes import TextElement, Inline, Text
+ from docutils.parsers.rst import Directive, directives
+ from docutils.writers.html4css1 import Writer, HTMLTranslator
+
+
+ class UnfuckedHTMLTranslator(HTMLTranslator):
+ def __init__(self, *args, **kwargs):
+ super().__init__(*args, **kwargs)
+ self.in_literal_block = False
+
+ def visit_literal_block(self, node):
+ # Insert an empty "lineno" span before each line. We insert the line numbers using pure CSS in a ::before
+ # pseudo-element. This has the added advantage that the line numbers don't get included in text selection.
+ # These line number spans are also used to show line continuation markers when a line is wrapped.
+ self.in_literal_block = True
+ self.body.append(self.starttag(node, 'pre', CLASS='literal-block'))
+ self.body.append('')
+
+ def depart_literal_block(self, node):
+ self.in_literal_block = False
+ self.body.append('\n
\n')
+
+ def visit_Text(self, node):
+ if self.in_literal_block:
+ for match in re.finditer('([^\n]*)(\n|$)', node.astext()):
+ text, end = match.groups()
+
+ if text:
+ super().visit_Text(Text(text))
+
+ if end == '\n':
+ if isinstance(node.parent, Inline):
+ self.depart_inline(node.parent)
+ self.body.append(f'\n')
+ if isinstance(node.parent, Inline):
+ self.visit_inline(node.parent)
+
+ else:
+ super().visit_Text(node)
+
+
+ html_writer = Writer()
+ html_writer.translator_class = UnfuckedHTMLTranslator
+ docutils.core.publish_cmdline(writer=html_writer)
+
+.. _Hugo: https://gohugo.io/
+.. _RestructuredText: https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
+.. _Pygments: https://pygments.org/
+.. _`monkey-patched`: https://en.wikipedia.org/wiki/Monkey_patch
+.. _`CSS Counter`: https://developer.mozilla.org/en-US/docs/Web/CSS/counter
diff --git a/content/blog/epa-sgd-crypto/index.rst b/content/blog/epa-sgd-crypto/index.rst
new file mode 100644
index 0000000..ccbf648
--- /dev/null
+++ b/content/blog/epa-sgd-crypto/index.rst
@@ -0,0 +1,100 @@
+---
+title: "75 Million Lives, Two Keys"
+date: 2025-01-05T23:42:00+01:00
+draft: true
+---
+
+2025 has begun. In this new year, with its new national healthcare record system, the country of Germany will start one
+of the largest rollouts of a cryptographic system in history. While the system has received scrutiny as well as
+resulting harsh criticism from a number of parties ranging from NGOs to everyday civilians, the system has received
+surprisingly little attention from the academic applied cryptography crowd. Additionally, previous criticism of
+the system has largely revolved around organizational issues. While valid, we belive that some cryptographic issues at
+the core of the system have escaped attention unitl now. In particular, at the core of the system is a key escrow system
+that contains several questionable design choices and that in its overall design seems out of place in 2025.
+
+The aim of the system is to serve as a shared storage for all healthcare records of a person. In the system, a person's
+entire patient file with all documentation on the treatment process including test results, images and other raw data
+will be stored in something vaguely resembling cloud storage such that all healthcare providers that the person visits
+can access the entire file. This centralized, synchronized storage eliminates the need for transferring this data
+between hospitals and doctors offices by fax, mail or physical media as it was common practice until now. After a
+development and testing phase lasting approximately five years, the German government decided to roll out the system to
+everybody insured under Germany's mandatory national health insurance scheme, totalling approximately 75 million people,
+on January 15th 2025.
+
+In this article, we will give an overview of the system's cryptographic design before highlighting a few odd
+design choices that could amount to a viable attack vector to the powerful adversaies
+
+## Context and involved parties
+
+Germany has a national, mandatory health insurance system. The system is open to any permanent resident of the country
+irrespective of citizenship. The system is mandatory in that while residents can choose between a number of both
+publically owned as well as private healthcare providers, it is not possible to opt out of the system. The public health
+insurance providers cover approximately 90% of German residents. These providers are organized in an umbrella
+organization named "GKV Spitzenverband". The resposibility of this umbrella organization largely revolves around
+negotiating prices with pharmaceutical companies and with healthcare providers as a publically sanctioned cartel, but
+also includes the specification and operation of shared IT infrastructure for billing and data exchange between
+healthcare providers.
+
+While GKV Spitzenverband is the party that ultimately holds responsibility for the regulatory administration of national
+healthcare IT infrastructure, it has delegated large parts of both the technical specification of this infrastructure as
+well as its day-to-day operation to Gematik GmbH, a state-owned limited liability corporation created specifically for
+the purpose of developing and implementing national healthcare IT standards. The electronic healthcare record system we
+describe in this article was standardized and implemented by Gematik GmbH under the direction of GKV Spitzenverband.
+
+Healthcare providers in Germany need to be registered with GKV Spitzenverband to serve members of public health
+insurance providers. Since these public providers constitute approximately 90% market share, the vast majority of
+healthcare providers are registered this way.
+
+Before the new national health record system, a number of healthcare IT processes have already been standardized and
+implemented by the parties above. In particular, every insured person already owns a cryptographic smartcard that acts
+as their proof of identity when accessing healthcare services. On the other side of such transactions, healthcare
+providers are likewise identified by cryptographic smartcards. Until now, these cards were used to facilitate billing of
+services from healthcare providers to insurers and to transfer prescriptions from prescribing doctors to pharmacies.
+
+A central role in this existing infrastructure is assumed by VPN gateways that link healthcare providers to
+the centrally-run backend infrastructure. Gematik GmbH calls these devices "Konnektor". They are specially-built
+hardware devices that contain multiple smart cards to authenticate the VPN connection towards the backend, and besides
+acting as a standard VPN gateway for client applications in the healthcare provider's network to tunnnel their backend
+requests through, the Konnektors also perform cryptographic operations in some of Gematik GmbH's protocols, such as
+authenticating certain requests using signatures.
+
+## Design principles
+
+The new health record system was built on top of the existing infrastructure described above. In particular, access to
+health records is managed through keys stored in the patient's and the healthcare provider's existing smartcards, and
+all backend communication is tunneled through the existing VPN. Access to the files is mediated through the healthcare
+provider's existing patient management software. While in early drafts of the system, access to healthcare records
+through the patient's smartcard was gated behind a PIN, the impracticality of making the entire patient populace
+remember PINs led the implementors to scrap this provision, meaning that the patient's smartcard is all a healthcare
+provider needs to access the patient's record.
+
+A critical cornerstone in the system's design is that the system's designers decided that a lost smartcard should not
+lead to any data loss. As a consequence of this decision, while some of the record's access keys are kept on the
+patient smartcard, in contravention to conventional smartcard designs the same keys are kept accessible in a centralized
+key escrow system named "Schlüsselgenerierungsdienst" and abbreviated as SGD. Furthermore, these keys are not generated
+on the smartcard either -- instead, the key escrow system generates these access keys, one copy of which is then
+transmitted and stored inside the smartcard.
+
+The system supports re-issuing a smartcard to gain access to a healthcare record. Since the record's privacy pivots on
+this process, the system incorporates some organziational countermeasures that aim to make it hard to gain access to a
+re-issued copy of a patient smartcard without the patient's help or otherwise multiple colluding parties.
+
+## Cryptographic design
+
+
+
+## The implied adversary model
+
+While Gematik GmbH publishes detailed specifications of the systems they standardize, these specifications and some
+associated implementation guidelines are about the extent of public information. Software implementations are being kept
+secret, and while standardization results are available, a large fraction of design rationale is discussed behind closed
+doors. From an academic perspective, the most glaring omission in Gematik GmbH's public documents is any definition of a
+threat model or an adversary model. As a result of this, we will deduce an adversary model below by contextualizing the
+published standards in the national healthcare setting. We will base our further analysis of the system on this
+adversary model.
+
+
+
+## Previous reviews and audits of the system
+
+[0] https://www.destatis.de/DE/Themen/Arbeit/Arbeitsmarkt/Qualitaet-Arbeit/Dimension-2/krankenversicherungsschutz.html
diff --git a/content/posts/hsm-basics/index.rst b/content/blog/hsm-basics/index.rst
similarity index 88%
rename from content/posts/hsm-basics/index.rst
rename to content/blog/hsm-basics/index.rst
index 99aedba..74b7275 100644
--- a/content/posts/hsm-basics/index.rst
+++ b/content/blog/hsm-basics/index.rst
@@ -1,11 +1,11 @@
---
title: "Hardware Security Module Basics"
date: 2019-05-17T15:29:20+08:00
+summary: >
+ I gave a short introduction into Hardware Security Modules at our university workgroup, including an overview on
+ interesting research directions.
---
-Hardware Security Modules and Security Research and Cryptography
-================================================================
-
On May 17 2019 I gave a short presentation on the fundamentals of hardware security modules at the weekly seminar of
Prof. Mori's security research working group at Waseda University. The motivation for this was that outside of low-level
hardware security people and people working in the financial industry HSMs are not thought about that often. In
@@ -113,21 +113,26 @@ The core component of an HSM blueprint would be a suite of tamper detection mech
to improve on the current state of the art of membrane tamper switches plus temperature sensors plus PCB and printed
security meshes plus potting.
-Improvements on existing techniques
------------------------------------
-
-Light sensors
-~~~~~~~~~~~~~
-**Advanced analog sensing**
-**Self-test functionality**
-
-Security meshes
-~~~~~~~~~~~~~~~
-**Analog sensing**
-
-
DIY or small lab mesh production
--------------------------------
+**Analog sensing** meshes are a proven technology where instead of just monitoring for continuity and shorts, analog
+parameters of the mesh traces such as inductance and mutual capacitance are monitored. In 2019, `Immler et al. published
+a paper `__ where took this principle and turned it all the
+way up. They directly derived a cryptographic secret from the analog properties of their HSM's security mesh in an
+attempt to built a `Physically Unclonable Function, or PUF
+`__. The idea with PUFs is that they reproduce some entropy
+that comes from random tolerances of their production process. The same PUF will always yield (approximately) the same
+key, but since you cannot control these random production variations, in practice the resulting PUF cannot be cloned.
+Note however, that its secrets can of course be copied if you find a way to read them out.
+
+As Immler et al. demonstrated in their paper, you don't need any secret sauce to create an analog mesh sensing circuit.
+All you need are a bunch of (admittedly, expensive) off-the-shelf analog ICs. The interesting bit here is that by
+applying more advanced analog sensing, weaknesses of an otherwise coarse mesh desing could maybe be alleviated. That is,
+instead of monitoring a very fine mesh for continuity, you could instead closely monitor inductance and capacitance of a
+more coarse mesh. This trade-off between sensing circuit complexity (resp. cost) and mesh production capabilities may
+allow someone with a poorly equipped lab to still make a decent HSM. The question is, how do you produce a "decent" mesh
+given only basic tools? Here are some ideas.
+
**3D metal patterning techniques** refers to any technique for producing thin, patterned metal structures on a
three-dimensional plastic substrate. The basic process would consist of 3D-printing the polymer substrate, depositing a
thin metal layer on top and then patterning this metal layer. A good starting point here would be the recent work of
diff --git a/content/posts/hsm-basics/mori_semi_hsm_talk_web.pdf b/content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf
similarity index 100%
rename from content/posts/hsm-basics/mori_semi_hsm_talk_web.pdf
rename to content/blog/hsm-basics/mori_semi_hsm_talk_web.pdf
diff --git a/content/blog/ihsm-worlds-first-diy-hsm/index.rst b/content/blog/ihsm-worlds-first-diy-hsm/index.rst
new file mode 100644
index 0000000..22cf8e4
--- /dev/null
+++ b/content/blog/ihsm-worlds-first-diy-hsm/index.rst
@@ -0,0 +1,44 @@
+---
+title: "New Paper on Inertial Hardware Security Modules"
+date: 2021-11-23T23:42:20+01:00
+summary: >
+ Paper announcement: We have published a paper on how you can DIY a tamper-sensing hardware security module from any
+ single-board computer using a moving tamper-sensing mesh made from cheap PCBs.
+---
+
+World's First DIY HSM
+=====================
+
+Last week, Prof. Dr. Björn Scheuermann and I have `published our first joint paper on Hardware Security Modules
+`__. In our paper, we introduce Inertial Hardware Security
+Modules (IHSMs), a new way of building high-security HSMs from basic components. I think the technology we demonstrate
+in our paper might allow some neat applications where some civil organization deploys a service that no one, not even
+they themselves, can snoop on. Anyone can built an IHSM without needing any fancy equipment, which makes me optimistic
+that maybe the ideas of the `Cypherpunk movement `__ aren't obsolete
+after all, despite even the word "crypto" having been co-opted by radical capitalist environmental destructionists.
+
+An IHSM is basically an ultra-secure enclosure for something like a server or a raspberry pi that even someone with
+unlimited resources would have a really hard time cracking without destroying all data stored in it. The principle of an
+IHSM is the same as that of a `normal HSM`_. You have a payload that contains really secret data. There's really no way
+to prevent an attacker with physical access to the thing from opening it given enough time and abrasive discs for their
+angle grinder. So what you do instead is that you make it self-destruct its secrets within microseconds of anyone
+tampering with it. Usually, such HSMs are used for storing credit card pins and other financial data. They're expensive
+as fuck, all the while being about the same processing speed as a smartphone. Traditional HSMs use printed or
+lithographically patterned conductive foils for their security mesh. These foils are not an off-the-shelf component and
+are made in a completely custom manufacturing process. To create your own, you would have to re-engineer that entire
+process and probably spend some serious money on production machines.
+
+Inertial HSMs take the concept of traditional HSMs, but replace the usual tamper detection mesh with a few security mesh
+PCBs. These PCBs are coarser than traditional meshes by orders of magnitude, and would alone not even be close to enough
+to keep out even a moderately motivated attacker. IHSMs fix this issue by spinning the entire tamper detection mesh at
+very high speed. To tamper with the mesh, an attacker would have to stop it. This, in turn, can be easily detected by
+the mesh's alarm circuitry using a simple accelerometer as a rotation sensor.
+
+In our paper, we have shown a working prototype of the core concepts one needs to build such an IHSM. To build an IHSM
+you only need a basic electronics lab. I built the prototype in our paper at home during one of Germany's COVID
+lockdowns. You can have a look at our code and CAD on `my git `__. What is missing right
+now is an integration of all of these fragments into something cohesive that an interested person with the right tools
+could go out and build. We are planning to release this sort of documentation at some point, but right now we are
+focusing our effort on the next iteration of the design instead. Stay tuned for updates ;)
+
+.. _`normal HSM`: {{}}
diff --git a/content/blog/jupyterlab-notebook-file-oneliner/index.rst b/content/blog/jupyterlab-notebook-file-oneliner/index.rst
new file mode 100644
index 0000000..5a543de
--- /dev/null
+++ b/content/blog/jupyterlab-notebook-file-oneliner/index.rst
@@ -0,0 +1,21 @@
+---
+title: "Getting the .ipynb Notebook File Location From a Running Jupyter Lab Notebook"
+date: 2025-06-29T23:42:00+01:00
+summary: >
+ If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It
+ seems chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to
+ me.
+---
+
+If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It seems
+chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to me.
+
+.. code:: python
+
+ import sys
+ Path(json.loads(Path(sys.argv[-1]).read_bytes())['jupyter_session'])
+
+The way this works is that for each notebook, jupyter starts a python "kernel" process that actually runs the notebook's
+code. That kernel gets a json file with info on the notebook's location on the disk passed through its command line.
+Since we're running code in that exact python process, we can just grab that json file from sys.argv, and read it
+ourselves.
diff --git a/content/posts/kicad-mesh-plugin/images/anim.webp b/content/blog/kicad-mesh-plugin/images/anim.webp
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/anim.webp
rename to content/blog/kicad-mesh-plugin/images/anim.webp
diff --git a/content/posts/kicad-mesh-plugin/images/cells-0.svg b/content/blog/kicad-mesh-plugin/images/cells-0.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/cells-0.svg
rename to content/blog/kicad-mesh-plugin/images/cells-0.svg
diff --git a/content/posts/kicad-mesh-plugin/images/cells-100.svg b/content/blog/kicad-mesh-plugin/images/cells-100.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/cells-100.svg
rename to content/blog/kicad-mesh-plugin/images/cells-100.svg
diff --git a/content/posts/kicad-mesh-plugin/images/cells-25.svg b/content/blog/kicad-mesh-plugin/images/cells-25.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/cells-25.svg
rename to content/blog/kicad-mesh-plugin/images/cells-25.svg
diff --git a/content/posts/kicad-mesh-plugin/images/cells-50.svg b/content/blog/kicad-mesh-plugin/images/cells-50.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/cells-50.svg
rename to content/blog/kicad-mesh-plugin/images/cells-50.svg
diff --git a/content/posts/kicad-mesh-plugin/images/cells-75.svg b/content/blog/kicad-mesh-plugin/images/cells-75.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/cells-75.svg
rename to content/blog/kicad-mesh-plugin/images/cells-75.svg
diff --git a/content/posts/kicad-mesh-plugin/images/grid-vis-plain.svg b/content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/grid-vis-plain.svg
rename to content/blog/kicad-mesh-plugin/images/grid-vis-plain.svg
diff --git a/content/posts/kicad-mesh-plugin/images/grid-vis.svg b/content/blog/kicad-mesh-plugin/images/grid-vis.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/grid-vis.svg
rename to content/blog/kicad-mesh-plugin/images/grid-vis.svg
diff --git a/content/posts/kicad-mesh-plugin/images/kicad-mesh-outline.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/kicad-mesh-outline.png
rename to content/blog/kicad-mesh-plugin/images/kicad-mesh-outline.png
diff --git a/content/posts/kicad-mesh-plugin/images/kicad-mesh-result-large.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/kicad-mesh-result-large.png
rename to content/blog/kicad-mesh-plugin/images/kicad-mesh-result-large.png
diff --git a/content/posts/kicad-mesh-plugin/images/kicad-mesh-settings.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/kicad-mesh-settings.png
rename to content/blog/kicad-mesh-plugin/images/kicad-mesh-settings.png
diff --git a/content/posts/kicad-mesh-plugin/images/kicad-mesh-settings2.png b/content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/kicad-mesh-settings2.png
rename to content/blog/kicad-mesh-plugin/images/kicad-mesh-settings2.png
diff --git a/content/posts/kicad-mesh-plugin/images/maze_tiles.svg b/content/blog/kicad-mesh-plugin/images/maze_tiles.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/maze_tiles.svg
rename to content/blog/kicad-mesh-plugin/images/maze_tiles.svg
diff --git a/content/posts/kicad-mesh-plugin/images/maze_tiles_plain.svg b/content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/maze_tiles_plain.svg
rename to content/blog/kicad-mesh-plugin/images/maze_tiles_plain.svg
diff --git a/content/posts/kicad-mesh-plugin/images/modern_art.svg b/content/blog/kicad-mesh-plugin/images/modern_art.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/modern_art.svg
rename to content/blog/kicad-mesh-plugin/images/modern_art.svg
diff --git a/content/posts/kicad-mesh-plugin/images/tiles-25-small.svg b/content/blog/kicad-mesh-plugin/images/tiles-25-small.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/tiles-25-small.svg
rename to content/blog/kicad-mesh-plugin/images/tiles-25-small.svg
diff --git a/content/posts/kicad-mesh-plugin/images/traces-25-small.svg b/content/blog/kicad-mesh-plugin/images/traces-25-small.svg
similarity index 100%
rename from content/posts/kicad-mesh-plugin/images/traces-25-small.svg
rename to content/blog/kicad-mesh-plugin/images/traces-25-small.svg
diff --git a/content/posts/kicad-mesh-plugin/index.rst b/content/blog/kicad-mesh-plugin/index.rst
similarity index 86%
rename from content/posts/kicad-mesh-plugin/index.rst
rename to content/blog/kicad-mesh-plugin/index.rst
index 85b407c..0969bf3 100644
--- a/content/posts/kicad-mesh-plugin/index.rst
+++ b/content/blog/kicad-mesh-plugin/index.rst
@@ -1,12 +1,16 @@
---
title: "Kicad Mesh Plugin"
date: 2020-08-18T13:15:39+02:00
+summary: >
+ I wrote a little KiCad plugin that you can use to create security meshes, heaters and other things where you need
+ one or more traces cover the entire surface of a PCB. The plugin supports arbitrary PCB shapes, cutouts, and can
+ route around existing footprints and traces on the PCB.
---
.. raw:: html
-
-
+
+
Tamper Detection Meshes
@@ -38,7 +42,7 @@ stored on the card, things such as copying of a card can only be hindered by mak
.. raw:: html
-
+
@@ -68,7 +72,7 @@ DIY Meshes
Throughout my studies in security research I have always had an interest in HSMs. I have taken apart my fair share of
HSMs and at this point, to understand the technology more, I want to experiment with building my own HSM. In last year's
-`HSM basics <{{}}>`_ post I have lined out some ideas for a next generation design that
+`HSM basics <{{}}>`_ post I have lined out some ideas for a next generation design that
deviates from the bread-and-butter apporoach of using a mesh as the primary security feature. Before embarking on
practical experiments with these ideas, I want to first take a stab at replicating the current state of the art as best
I can. State of the art meshes often use exotic substrates such as 3D plastic parts with traces chemically deposited on
@@ -93,7 +97,7 @@ usable for this task.
.. raw:: html
-
+ The process starts out with the mesh shape being defined inside KiCAD. The mesh's outline is drawn
@@ -104,7 +108,7 @@ usable for this task.
.. raw:: html
-
+
@@ -125,25 +129,29 @@ means that on every step, the algorithm is choosing a new direction at random.
.. raw:: html
-
-
-
- 0%
-
-
- 25%
-
-
- 50%
-
-
- 75%
-
-
- 100%
-
-
+
After I have built this tree like you would do in a depth-first search, I draw my one or several mesh mesh traces into
it. The core observation here is that there is only 16 possible ways a cell can be connected: It has four neighbors,
@@ -153,7 +161,7 @@ sides connected, a straight through, a 90 degree bend, and a "T"-junction—see
.. raw:: html
-
+
There are six possible tile types in our connectivity graph inside its square tiling. This graphic illustrates
@@ -165,7 +173,7 @@ After tiling the grid according to the key above, we get the result below.
.. raw:: html
-
+
An auto-routed mesh with traces colored according to tile types.
@@ -174,7 +182,7 @@ After tiling the grid according to the key above, we get the result below.
.. raw:: html
-
+
The same mesh, but with traces all black.
@@ -185,7 +193,7 @@ Putting it all together got me the KiCAD plugin you can see in the screenshot be
.. raw:: html
-
+
The plugin settings window open.
@@ -194,11 +202,11 @@ Putting it all together got me the KiCAD plugin you can see in the screenshot be
.. raw:: html
-
-
-
- After runing the plugin, the generated mesh looks like this in pcbnew.
-
+
+
+
+ After runing the plugin, the generated mesh looks like this in pcbnew.
+
I am fairly happy with the result, but getting there was a medium pain. Especially KiCAD's plugin API is still very
@@ -214,7 +222,7 @@ making a copy of the board file first and treating mesh generation as a non-reve
.. raw:: html
-
+
diff --git a/content/blog/kicoil-theory/header.png b/content/blog/kicoil-theory/header.png
new file mode 100644
index 0000000..2b95b66
Binary files /dev/null and b/content/blog/kicoil-theory/header.png differ
diff --git a/content/blog/kicoil-theory/index.rst b/content/blog/kicoil-theory/index.rst
new file mode 100644
index 0000000..c746cea
--- /dev/null
+++ b/content/blog/kicoil-theory/index.rst
@@ -0,0 +1,40 @@
+---
+title: "The KiCoil Planar Coil Generator"
+date: 2025-12-31T13:15:39+02:00
+summary: >
+ I wrote a layout tool generating planar coils that can handle spiral coils, toroidal coils, and hybrids in between
+ the two.
+---
+
+.. raw:: html
+
+
+
+
+
+A planar coil is a coil that is made from flat traces in some printing process like PCB or IC manufacturing, instead of
+being wound from wire. A few weeks ago, I needed one such planar coil that
+
+
+Project State
+-------------
+
+Currently, circular coils are special cased. Their layouts are directly generated, without the use of polygon
+offsetting. Windings are efficiently approximated using circular arcs. The circular coil layout code is solid, and
+contains decent (albeit not infallible) parameter sanity checks. Its main limitation is that sometimes, clearances can
+be violated a bit.
+
+The arbitrary shape code path is less stable, and produces faulty output in some cases. The most common error is
+crossing traces near the first vertex of the polygon when the polygon has highly convex or concave parts. I'm still
+improving this code path, but as long as you check the output, any errors it produces should be easy to fix by hand.
+
+If you would like to contribute, I'd welcome any ideas on the arbitrary shape code path. I think there is no single
+optimal solution here, and a generic algorithm that can be adjusted to favor for instance shape accuracy versus winding
+smoothness would be nice.
+
+All project links are listed on `https://jaseg.de/projects/kicoil/ `__. You can check
+out the code on my git at `https://git.jaseg.de/kicoil.git `__. Issues are tracked on
+codeberg at `https://codeberg.org/jaseg/kicoil `__. The kicad addon can be installed
+from the KiCad plugin manager, and you can install the standalone kicoil python package `from PyPI
+`__.
+
diff --git a/content/posts/led-characterization/images/daylight_spectrum_dvd.jpg b/content/blog/led-characterization/images/daylight_spectrum_dvd.jpg
similarity index 100%
rename from content/posts/led-characterization/images/daylight_spectrum_dvd.jpg
rename to content/blog/led-characterization/images/daylight_spectrum_dvd.jpg
diff --git a/content/posts/led-characterization/images/driver_ringing_strong.jpg b/content/blog/led-characterization/images/driver_ringing_strong.jpg
similarity index 100%
rename from content/posts/led-characterization/images/driver_ringing_strong.jpg
rename to content/blog/led-characterization/images/driver_ringing_strong.jpg
diff --git a/content/posts/led-characterization/images/driver_ringing_weak.jpg b/content/blog/led-characterization/images/driver_ringing_weak.jpg
similarity index 100%
rename from content/posts/led-characterization/images/driver_ringing_weak.jpg
rename to content/blog/led-characterization/images/driver_ringing_weak.jpg
diff --git a/content/posts/led-characterization/images/electronics_whole.jpg b/content/blog/led-characterization/images/electronics_whole.jpg
similarity index 100%
rename from content/posts/led-characterization/images/electronics_whole.jpg
rename to content/blog/led-characterization/images/electronics_whole.jpg
diff --git a/content/posts/led-characterization/images/hsv_cylinder.png b/content/blog/led-characterization/images/hsv_cylinder.png
similarity index 100%
rename from content/posts/led-characterization/images/hsv_cylinder.png
rename to content/blog/led-characterization/images/hsv_cylinder.png
diff --git a/content/posts/led-characterization/images/photodiode_sensitivity.svg b/content/blog/led-characterization/images/photodiode_sensitivity.svg
similarity index 100%
rename from content/posts/led-characterization/images/photodiode_sensitivity.svg
rename to content/blog/led-characterization/images/photodiode_sensitivity.svg
diff --git a/content/posts/led-characterization/images/preamp_back.jpg b/content/blog/led-characterization/images/preamp_back.jpg
similarity index 100%
rename from content/posts/led-characterization/images/preamp_back.jpg
rename to content/blog/led-characterization/images/preamp_back.jpg
diff --git a/content/posts/led-characterization/images/preamp_front.jpg b/content/blog/led-characterization/images/preamp_front.jpg
similarity index 100%
rename from content/posts/led-characterization/images/preamp_front.jpg
rename to content/blog/led-characterization/images/preamp_front.jpg
diff --git a/content/posts/led-characterization/images/preamp_schematic.jpg b/content/blog/led-characterization/images/preamp_schematic.jpg
similarity index 100%
rename from content/posts/led-characterization/images/preamp_schematic.jpg
rename to content/blog/led-characterization/images/preamp_schematic.jpg
diff --git a/content/posts/led-characterization/images/processed_plot_cheap_rgb.svg b/content/blog/led-characterization/images/processed_plot_cheap_rgb.svg
similarity index 100%
rename from content/posts/led-characterization/images/processed_plot_cheap_rgb.svg
rename to content/blog/led-characterization/images/processed_plot_cheap_rgb.svg
diff --git a/content/posts/led-characterization/images/raw_plot_cheap_rgb.svg b/content/blog/led-characterization/images/raw_plot_cheap_rgb.svg
similarity index 100%
rename from content/posts/led-characterization/images/raw_plot_cheap_rgb.svg
rename to content/blog/led-characterization/images/raw_plot_cheap_rgb.svg
diff --git a/content/posts/led-characterization/images/rgb_cube.svg b/content/blog/led-characterization/images/rgb_cube.svg
similarity index 100%
rename from content/posts/led-characterization/images/rgb_cube.svg
rename to content/blog/led-characterization/images/rgb_cube.svg
diff --git a/content/posts/led-characterization/images/spectrograph_step1_parts.jpg b/content/blog/led-characterization/images/spectrograph_step1_parts.jpg
similarity index 100%
rename from content/posts/led-characterization/images/spectrograph_step1_parts.jpg
rename to content/blog/led-characterization/images/spectrograph_step1_parts.jpg
diff --git a/content/posts/led-characterization/images/spectrograph_step2.jpg b/content/blog/led-characterization/images/spectrograph_step2.jpg
similarity index 100%
rename from content/posts/led-characterization/images/spectrograph_step2.jpg
rename to content/blog/led-characterization/images/spectrograph_step2.jpg
diff --git a/content/posts/led-characterization/images/spectrograph_step3.jpg b/content/blog/led-characterization/images/spectrograph_step3.jpg
similarity index 100%
rename from content/posts/led-characterization/images/spectrograph_step3.jpg
rename to content/blog/led-characterization/images/spectrograph_step3.jpg
diff --git a/content/posts/led-characterization/images/spectrograph_step4_complete.jpg b/content/blog/led-characterization/images/spectrograph_step4_complete.jpg
similarity index 100%
rename from content/posts/led-characterization/images/spectrograph_step4_complete.jpg
rename to content/blog/led-characterization/images/spectrograph_step4_complete.jpg
diff --git a/content/posts/led-characterization/images/zeus_hammer_breadboard.jpg b/content/blog/led-characterization/images/zeus_hammer_breadboard.jpg
similarity index 100%
rename from content/posts/led-characterization/images/zeus_hammer_breadboard.jpg
rename to content/blog/led-characterization/images/zeus_hammer_breadboard.jpg
diff --git a/content/posts/led-characterization/images/zeus_hammer_breadboard_original.jpg b/content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg
similarity index 100%
rename from content/posts/led-characterization/images/zeus_hammer_breadboard_original.jpg
rename to content/blog/led-characterization/images/zeus_hammer_breadboard_original.jpg
diff --git a/content/posts/led-characterization/images/zeus_hammer_schematic.jpg b/content/blog/led-characterization/images/zeus_hammer_schematic.jpg
similarity index 100%
rename from content/posts/led-characterization/images/zeus_hammer_schematic.jpg
rename to content/blog/led-characterization/images/zeus_hammer_schematic.jpg
diff --git a/content/posts/led-characterization/images/zeus_hammer_schematic_original.jpg b/content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg
similarity index 100%
rename from content/posts/led-characterization/images/zeus_hammer_schematic_original.jpg
rename to content/blog/led-characterization/images/zeus_hammer_schematic_original.jpg
diff --git a/content/posts/led-characterization/index.rst b/content/blog/led-characterization/index.rst
similarity index 95%
rename from content/posts/led-characterization/index.rst
rename to content/blog/led-characterization/index.rst
index 6a8c7ee..31e81cc 100644
--- a/content/posts/led-characterization/index.rst
+++ b/content/blog/led-characterization/index.rst
@@ -1,6 +1,12 @@
---
title: "LED Characterization"
date: 2018-05-02T11:18:38+02:00
+summary: >
+ Recently, I have been working on a small driver for ambient lighting using 12V LED strips like you can get
+ inexpensively from China. I wanted to be able to just throw one of these somewhere, stick down some LED tape, hook
+ it up to a small transformer and be able to control it through Wifi. When I was writing the firmware, I noticed that
+ when fading between different colors, the colors look *all wrong*! This observation led me down a rabbit hole of
+ color perception and LED peculiarities.
---
Preface
@@ -19,7 +25,7 @@ really important so you could dim it down a lot without flickering. I ended up u
.. raw:: html
-
+ An illustration of the RGB color cube.
Picture by
@@ -46,7 +52,7 @@ transformation.
.. raw:: html
-
+ An illustration of the HSV color space as a cylinder.
Picture by
@@ -67,7 +73,7 @@ particular in the blues and greens we loose *a lot* of colors to sRGB.
.. raw:: html
-
+
+ 
+ 
@@ -125,25 +129,29 @@ means that on every step, the algorithm is choosing a new direction at random.
.. raw:: html
- 
- 
- 
- 
- 
- 
- 
+ 
