<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>encryption on toorun.dev</title><link>https://toorun.dev/tags/encryption/</link><description>Recent content in encryption on toorun.dev</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 06 Oct 2026 10:00:00 +0000</lastBuildDate><atom:link href="https://toorun.dev/tags/encryption/index.xml" rel="self" type="application/rss+xml"/><item><title>Firmware Signing vs Encryption: Secure Updates, Secure Boot, and Read-Only Embedded Systems</title><link>https://toorun.dev/posts/firmware-signing-encryption-secure-boot-embedded-linux-mcu/</link><pubDate>Tue, 06 Oct 2026 10:00:00 +0000</pubDate><guid>https://toorun.dev/posts/firmware-signing-encryption-secure-boot-embedded-linux-mcu/</guid><description>Firmware Signing vs Encryption: Secure Updates, Secure Boot, and Read-Only Embedded Systems Imagine an industrial controller receiving a firmware update over Ethernet, or a technician inserting a USB stick into an embedded Linux gateway. How does the device know the file came from its manufacturer? Can someone replace it with malicious code? Can a competitor read the software? What happens if power fails halfway through installation?
These are different problems. Signing proves authorization and detects modification.</description></item></channel></rss>