<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Documentation on Longfellow</title><link>https://longfellow-zk.github.io/longfellow-zk/docs/</link><description>Recent content in Documentation on Longfellow</description><generator>Hugo</generator><language>en</language><atom:link href="https://longfellow-zk.github.io/longfellow-zk/docs/index.xml" rel="self" type="application/rss+xml"/><item><title>Using ZK in Identity Protocols</title><link>https://longfellow-zk.github.io/longfellow-zk/docs/protocols/</link><pubDate>Thu, 25 Sep 2025 00:00:00 +0000</pubDate><guid>https://longfellow-zk.github.io/longfellow-zk/docs/protocols/</guid><description>&lt;h3 id="how-to-request-a-zk-proof-via-openid"&gt;How to request a ZK proof via openid&lt;a class="td-heading-self-link" href="#how-to-request-a-zk-proof-via-openid" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;Here is a proposed method to use the openid4vp framework to request a ZK proof. Openid4vp is an under-specified framework designed to encapsulate any specific identity format. One idea is for the &lt;code&gt;dcql_query&lt;/code&gt; element to contain enough information to identity a ZK system, a ZK circuit, and a ZK theorem which defines the set of acceptable respose messages.&lt;/p&gt;
&lt;p&gt;In the example below, the only differences with a standard &lt;code&gt;mdoc&lt;/code&gt; request occur in the &lt;code&gt;format&lt;/code&gt; and &lt;code&gt;meta&lt;/code&gt; components: the special &lt;code&gt;mso_mdoc_zk&lt;/code&gt; format value, and
the inclusion of &lt;code&gt;zk_system_type&lt;/code&gt; and &lt;code&gt;verifier_message&lt;/code&gt;, which are defined in the ISO 18013-5 second edition, section 10.3.4.&lt;/p&gt;</description></item><item><title>Reviews</title><link>https://longfellow-zk.github.io/longfellow-zk/docs/reviews/</link><pubDate>Mon, 01 Sep 2025 00:00:00 +0000</pubDate><guid>https://longfellow-zk.github.io/longfellow-zk/docs/reviews/</guid><description>&lt;p&gt;This page documents the security reviews of Longfellow that have been completed by external organizations.&lt;/p&gt;
&lt;h2 id="trail-of-bits"&gt;Trail of Bits&lt;a class="td-heading-self-link" href="#trail-of-bits" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Trail of Bits has reviewed our system and produced a
&lt;a href="../../reviews/Longfellow_report_2025_08_18.pdf"&gt;report&lt;/a&gt;. All of the issues have been addressed in the latest release. To briefly comment on the issues marked &amp;ldquo;High&amp;rdquo; severity:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;Issue #1: The report noted that our library does not read each circuit to verify its hash. Because our library is intended to be used in a high-performance server, our library provides these methods, but does not perform the check in &lt;em&gt;each&lt;/em&gt; call to the verifier method. Instead, we expect a proper verifier implementation to perform this costly check once upon start and then cache the circuits in memory. Our reference verifier implementation illustrates how this can be done.&lt;/p&gt;</description></item><item><title>Benchmarks</title><link>https://longfellow-zk.github.io/longfellow-zk/docs/benchmarks/</link><pubDate>Sat, 05 Jul 2025 00:00:00 +0000</pubDate><guid>https://longfellow-zk.github.io/longfellow-zk/docs/benchmarks/</guid><description>&lt;p&gt;This page documents the results of some of our benchmark suite on different hardware. All of our code runs &lt;em&gt;single threaded&lt;/em&gt; for deployment purposes. It is important not to consume a user&amp;rsquo;s battery.&lt;/p&gt;
&lt;h2 id="mac-m4"&gt;Mac M4&lt;a class="td-heading-self-link" href="#mac-m4" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;h3 id="fft"&gt;FFT&lt;a class="td-heading-self-link" href="#fft" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;Because Longfellow uses the Ligero proof system as a component, the FFT may be a bottleneck (without other measures). This benchmark measures the FFT time over different fields. Note that we have another, more realistic &lt;em&gt;interpolation&lt;/em&gt; benchmark that measures the Reed-Solomon encoding time. However, this benchmark provides a good method to compare against other implementations. The Fp2 field is the quadratic extension over the P256 prime. The Fp128 and Fp64 fields are prime fields of size 128- and 64- bits respectively, and the Fp64_2 field is the quadratic extension of the later.&lt;/p&gt;</description></item><item><title>Draft Specs</title><link>https://longfellow-zk.github.io/longfellow-zk/docs/spec/</link><pubDate>Sat, 05 Jul 2025 00:00:00 +0000</pubDate><guid>https://longfellow-zk.github.io/longfellow-zk/docs/spec/</guid><description>&lt;ul&gt;
&lt;li&gt;&lt;a href="../../spec/draft-google-cfrg-libzk-01.html"&gt;Latest version of IETF draft&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>Longfellow ZK System spec parameters</title><link>https://longfellow-zk.github.io/longfellow-zk/docs/zk-system-spec/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://longfellow-zk.github.io/longfellow-zk/docs/zk-system-spec/</guid><description>&lt;p&gt;ISO 18013-5 and and OpenId4VP allow RPs to request ZKP responses and specify any ZKP system and some parameters required to make sure RP will be able to verify the proof correctly.
The list of the parameters and their values are not defined in the standard and are specific for each ZKP system.&lt;/p&gt;
&lt;p&gt;This document describes which parameters should be used by users of Longfellow ZK System. Those parameters are currently used by Google Wallet and Multipaz Wallet/RP.&lt;/p&gt;</description></item></channel></rss>