<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>hashes &#8211; Noise</title>
	<atom:link href="https://noise.getoto.net/tag/hashes/feed/" rel="self" type="application/rss+xml" />
	<link>https://noise.getoto.net</link>
	<description>The collective thoughts of the interwebz</description>
	<lastBuildDate>Mon, 08 Sep 2025 16:23:50 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.8.2</generator>
	<item>
		<title>New Cryptanalysis of the Fiat-Shamir Protocol</title>
		<link>https://noise.getoto.net/2025/09/09/new-cryptanalysis-of-the-fiat-shamir-protocol/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Tue, 09 Sep 2025 11:02:00 +0000</pubDate>
				<category><![CDATA[academic papers]]></category>
		<category><![CDATA[cryptanalysis]]></category>
		<category><![CDATA[hashes]]></category>
		<category><![CDATA[protocols]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=70685</guid>

					<description><![CDATA[<p>A couple of months ago, a <a href="https://eprint.iacr.org/2025/118">new paper</a> demonstrated some new attacks against the Fiat-Shamir transformation. <i>Quanta</i> published a <a href="https://www.quantamagazine.org/computer-scientists-figure-out-how-to-prove-lies-20250709/">good article</a> that explains the results.</p>
<p>This is a pretty exciting paper from a theoretical perspective, but I don’t see it leading to any practical real-world cryptanalysis. The fact that there are some weird circumstances that result in Fiat-Shamir insecurities isn’t new—many dozens of papers have been published about it since 1986. What this new result does is extend this known problem to slightly less weird (but still highly contrived) situations. But it’s a completely different matter to extend these sorts of attacks to “natural” situations...</p>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Good Essay on the History of Bad Password Policies</title>
		<link>https://noise.getoto.net/2024/11/15/good-essay-on-the-history-of-bad-password-policies/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Fri, 15 Nov 2024 12:05:02 +0000</pubDate>
				<category><![CDATA[hashes]]></category>
		<category><![CDATA[history of security]]></category>
		<category><![CDATA[passwords]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=69596</guid>

					<description><![CDATA[<p>Stuart Schechter makes some <a href="https://stuartschechter.org/posts/password-history/">good points</a> on the history of bad password policies:</p>
<blockquote><p>Morris and Thompson’s work brought much-needed data to highlight a problem that lots of people suspected was bad, but that had not been studied scientifically. Their work was a big step forward, if not for two mistakes that would impede future progress in improving passwords for decades.</p>
<p>First, was Morris and Thompson’s confidence that their solution, a password policy, would fix the underlying problem of weak passwords. They incorrectly assumed that if they prevented the specific categories of weakness that they had noted, that the result would be something strong. After implementing a requirement that password have multiple characters sets or more total characters, they wrote:...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>More on Apple’s iPhone Backdoor</title>
		<link>https://noise.getoto.net/2021/08/20/more-on-apples-iphone-backdoor/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Fri, 20 Aug 2021 13:54:51 +0000</pubDate>
				<category><![CDATA[Apple]]></category>
		<category><![CDATA[backdoors]]></category>
		<category><![CDATA[hashes]]></category>
		<category><![CDATA[photos]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[surveillance]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=63595</guid>

					<description><![CDATA[<p>In this post, I’ll collect links on Apple’s iPhone backdoor for scanning CSAM images. Previous links are <a href="https://www.schneier.com/blog/archives/2021/08/apple-adds-a-backdoor-to-imesssage-and-icloud-storage.html">here</a> and <a href="https://www.schneier.com/blog/archives/2021/08/apples-neuralhash-algorithm-has-been-reverse-engineered.html">here</a>.</p>
<p>Apple <a href="https://www.theverge.com/2021/8/18/22630439/apple-csam-neuralhash-collision-vulnerability-flaw-cryptography">says</a> that hash collisions in its CSAM detection system were expected, and not a concern. I’m not convinced that this secondary system was originally part of the design, since it wasn’t discussed in the original specification.</p>
<p>Good <a href="https://www.washingtonpost.com/opinions/2021/08/19/apple-csam-abuse-encryption-security-privacy-dangerous/">op-ed</a> from a group of Princeton researchers who developed a similar system:</p>
<blockquote><p>Our system could be easily repurposed for surveillance and censorship. The design wasn’t restricted to a specific category of content; a service could simply swap in any content-matching database, and the person using that service would be none the wiser...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Apple’s NeuralHash Algorithm Has Been Reverse-Engineered</title>
		<link>https://noise.getoto.net/2021/08/18/apples-neuralhash-algorithm-has-been-reverse-engineered/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Wed, 18 Aug 2021 16:51:17 +0000</pubDate>
				<category><![CDATA[algorithms]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[backdoors]]></category>
		<category><![CDATA[Cryptography]]></category>
		<category><![CDATA[hashes]]></category>
		<category><![CDATA[ios]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[Reverse Engineering]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=63588</guid>

					<description><![CDATA[<p>Apple’s <a href="https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf">NeuralHash algorithm</a> — the one it’s using for <a href="https://www.schneier.com/blog/archives/2021/08/apple-adds-a-backdoor-to-imesssage-and-icloud-storage.html">client-side scanning</a> on the iPhone — has been <a href="https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX">reverse-engineered</a>.</p>
<p>Turns out it was already in iOS 14.3, and <a href="https://www.reddit.com/r/MachineLearning/comments/p6hsoh/p_appleneuralhash2onnx_reverseengineered_apple/">someone noticed</a>:</p>
<blockquote><p>Early tests show that it can tolerate image resizing and compression, but not cropping or rotations.</p></blockquote>
<p>We also have the <a href="https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX/issues/1">first collision</a>: two images that hash to the same value.</p>
<p>The next step is to generate innocuous images that NeuralHash classifies as prohibited content.</p>
<p>This was a bad idea from the start, and Apple never seemed to consider the adversarial context of the system as a whole, and not just the cryptography...</p>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Brexit Deal Mandates Old Insecure Crypto Algorithms</title>
		<link>https://noise.getoto.net/2020/12/31/brexit-deal-mandates-old-insecure-crypto-algorithms/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Thu, 31 Dec 2020 12:19:14 +0000</pubDate>
				<category><![CDATA[aes]]></category>
		<category><![CDATA[algorithms]]></category>
		<category><![CDATA[Cryptography]]></category>
		<category><![CDATA[e-mail]]></category>
		<category><![CDATA[encryption]]></category>
		<category><![CDATA[hashes]]></category>
		<category><![CDATA[rsa]]></category>
		<category><![CDATA[UK]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=60696</guid>

					<description><![CDATA[<p>In what is surely an unthinking cut-and-paste issue, page 921 of the Brexit deal <a href="https://www.theverge.com/2020/12/29/22204624/brexit-eu-uk-netscape-communicator-4-crytography-email-data-dna-trade-deal">mandates</a> <a href="https://www.bbc.com/news/technology-55475433">the</a> use of SHA-1 and 1024-bit RSA:</p>
<blockquote><p>The open standard s/MIME as extension to de facto e-mail standard SMTP will be deployed to encrypt messages containing DNA profile information. The protocol s/MIME (V3) allows signed receipts, security labels, and secure mailing lists&#8230; The underlying certificate used by s/MIME mechanism has to be in compliance with X.509 standard&#8230;. The processing rules for s/MIME encryption operations&#8230; are as follows:</p>
<ol>
<li>the sequence of the operations is: first encryption and then signing,
...</li></ol></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
	</channel>
</rss>

<!--
Performance optimized by W3 Total Cache. Learn more: https://www.boldgrid.com/w3-total-cache/

Object Caching 21/133 objects using Memcached
Page Caching using Disk: Enhanced 
Lazy Loading (feed)
Database Caching using Memcached

Served from: noise.getoto.net @ 2025-12-10 19:31:05 by W3 Total Cache
-->