<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>The Effect of Length on Key Fingerprint Verification Security and Usability · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2306.04574/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2306.04574/feed.xml" rel="self" type="application/rss+xml" /><item><title>The Effect of Length on Key Fingerprint Verification Security and Usability — mentioned by doomrobo</title><link>https://news.ycombinator.com/item?id=45610566</link><guid isPermaLink="false">urn:hackerpapers:mention:2306.04574:45610566</guid><pubDate>Thu, 16 Oct 2025 20:55:29 GMT</pubDate><description>&lt;p&gt;I&amp;#x27;ll actually argue the opposite. Transparency is _the_ pivotal thing, and code signing needs to be built on top of it (it definitely should be built into the browser, but I&amp;#x27;m just arguing the order of operations rn). TL;DR you&amp;#x27;ll either re-invent transparency or end up with huge security holes. Suppose you have code signing and no transparency. Your site has some way of signaling to the browser to check code signatures under a certain pubkey (or OIDC identity if you&amp;#x27;re using Sigstore). Suppose now that your site is compromised. What is to prevent an attacker from changing the pubkey and…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2306.04574/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item></channel></rss>
