deploy: 696a62b

categories/index.xml

@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Categories on OpenMLS</title><link>https://blog.openmls.tech/categories/</link><description>Recent content in Categories on OpenMLS</description><generator>Hugo -- 0.134.0</generator><language>en-us</language><atom:link href="https://blog.openmls.tech/categories/index.xml" rel="self" type="application/rss+xml"/></channel></rss>
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Categories on OpenMLS</title><link>https://blog.openmls.tech/categories/</link><description>Recent content in Categories on OpenMLS</description><generator>Hugo -- 0.135.0</generator><language>en-us</language><atom:link href="https://blog.openmls.tech/categories/index.xml" rel="self" type="application/rss+xml"/></channel></rss>

index.xml

@@ -1,4 +1,5 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>OpenMLS</title><link>https://blog.openmls.tech/</link><description>Recent content on OpenMLS</description><generator>Hugo -- 0.134.0</generator><language>en-us</language><lastBuildDate>Wed, 04 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.openmls.tech/index.xml" rel="self" type="application/rss+xml"/><item><title>OpenMLS 0.6 released</title><link>https://blog.openmls.tech/posts/2024-09-04-v0_6-release/</link><pubDate>Wed, 04 Sep 2024 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2024-09-04-v0_6-release/</guid><description>&lt;p>Today, we are releasing version 0.6 of OpenMLS. In this post we’ll go over the most significant changes since our last release.&lt;/p>
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>OpenMLS</title><link>https://blog.openmls.tech/</link><description>Recent content on OpenMLS</description><generator>Hugo -- 0.135.0</generator><language>en-us</language><lastBuildDate>Mon, 30 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.openmls.tech/index.xml" rel="self" type="application/rss+xml"/><item><title>Taking Stock of Validation Checks</title><link>https://blog.openmls.tech/posts/2024-09-30-taking-stock-of-validation-checks/</link><pubDate>Mon, 30 Sep 2024 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2024-09-30-taking-stock-of-validation-checks/</guid><description>&lt;p>When implementing cryptographic protocols, probably the most important thing is to not forget validating all inputs. Failing to do so can lead to inadvertant leakage of private information, state corruption, impersonation attacks&amp;hellip; all kinds of vulnerabilities.&lt;/p>
+&lt;p>To give an example, you might remember &lt;a href="https://www.imperialviolet.org/2014/02/22/applebug.html">the &amp;ldquo;goto fail&amp;rdquo; vulnerability&lt;/a>, a bug in the TLS implementation used in iOS. Here, the verification function of signatures sent along with the &lt;code>ServerKeyExchange&lt;/code> message, which ties the server identity to the transcript and ephemeral key material. Due to a hard-to-spot slipup, it returned success early and never really checked the signature, which would allow an attacker to man-in-the-middle the connection. While in this case they didn&amp;rsquo;t just &lt;em>forget&lt;/em> to do the check, it does demonstrate why these checks are important.&lt;/p></description></item><item><title>OpenMLS 0.6 released</title><link>https://blog.openmls.tech/posts/2024-09-04-v0_6-release/</link><pubDate>Wed, 04 Sep 2024 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2024-09-04-v0_6-release/</guid><description>&lt;p>Today, we are releasing version 0.6 of OpenMLS. In this post we’ll go over the most significant changes since our last release.&lt;/p>
 &lt;h1 id="new-storage-provider">New Storage Provider&lt;/h1>
 &lt;p>To make it easier to persist group state, the &lt;code>KeyStoreProvider&lt;/code> was replaced with the more powerful &lt;code>StorageProvider&lt;/code> trait for tracking the state of a group or a party. This includes keys, but also other group state like the ratchet tree and the group context. OpenMLS writes to the storage at the end of any successful operation. This means that if the provider is backed by some persistent memory, the entire long-lived state of OpenMLS is automatically persisted.&lt;/p></description></item><item><title>Post-Quantum OpenMLS</title><link>https://blog.openmls.tech/posts/2024-04-11-pq-openmls/</link><pubDate>Thu, 11 Apr 2024 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2024-04-11-pq-openmls/</guid><description>Get started with post-quantum secure end-to-end encrypted with OpenMLS.</description></item><item><title>OpenMLS 0.5 released</title><link>https://blog.openmls.tech/posts/2023-07-20-v0_5-release/</link><pubDate>Thu, 20 Jul 2023 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2023-07-20-v0_5-release/</guid><description>&lt;p>Today, we are releasing OpenMLS v0.5. This release has been a while in the making and covers substantial changes since the last release. We are grateful for &lt;a href="https://openmls.tech/blog/2022-10-19-update/">the support of the Sovereign Tech Fund&lt;/a> towards this goal. These are some of the changes:&lt;/p>
 &lt;ul>
@@ -18,7 +19,8 @@ To achieve this we start by catching up with all the changes to the protocol
 towards a more comprehensive test framework for interoperability.&lt;/p></description></item><item><title>OpenMLS v0.4 Release</title><link>https://blog.openmls.tech/posts/2022-02-28-v0_4-release/</link><pubDate>Mon, 28 Feb 2022 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2022-02-28-v0_4-release/</guid><description>&lt;p>&lt;strong>Today, we are excited to announce the release of &lt;a href="https://github.com/openmls/openmls/releases/tag/v0.4.0">v0.4 of OpenMLS&lt;/a>! 🎉&lt;/strong>&lt;/p>
 &lt;p>Some time has passed since we wrote about our &lt;a href="https://openmls.tech/blog/2021-10-19-openmls-04-roadmap/">roadmap to v0.4&lt;/a>. In this post, we want to provide some insight into what has happened in the development of OpenMLS generally, but also relative to the goals we included in the roadmap.&lt;/p>
 &lt;p>Our high-level goal with v0.4 was to reach a state where we have an API stable enough and an implementation robust enough such that people interested in OpenMLS can start exploring it in the context of their own projects. However, this is not v1.0 and we can neither promise that the API won’t change in the future, nor do we advise using OpenMLS in production or indeed in any security-sensitive context. With this disclaimer out of the way, let’s see what has happened in these past months.&lt;/p></description></item><item><title>OpenMLS v0.4 Roadmap</title><link>https://blog.openmls.tech/posts/2021-10-19-openmls-04-roadmap/</link><pubDate>Tue, 19 Oct 2021 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2021-10-19-openmls-04-roadmap/</guid><description>&lt;p>It&amp;rsquo;s time for another update on OpenMLS because many things are happening behind the scenes.&lt;/p>
-&lt;p>Today we are excited to announce a public roadmap for OpenMLS v0.4. This will not even be close to a v1.0 release because the &lt;a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">spec&lt;/a> is still not finished and it&amp;rsquo;s unclear how the library will be used. Nonetheless will v0.4 be a significant release with a mostly stable API and most functionality being implemented.&lt;/p></description></item><item><title>OpenMLS Performance</title><link>https://blog.openmls.tech/posts/2021-05-18-openmls-first-benchmarks/</link><pubDate>Tue, 18 May 2021 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2021-05-18-openmls-first-benchmarks/</guid><description>&lt;p>In this blog post, I explore how MLS&amp;rsquo; aspiration &lt;a href="https://datatracker.ietf.org/doc/charter-ietf-mls/">to be scalable&lt;/a> manifests itself in OpenMLS.&lt;/p>
+&lt;p>Today we are excited to announce a public roadmap for OpenMLS v0.4. This will not even be close to a v1.0 release because the &lt;a href="https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/">spec&lt;/a> is still not finished and it&amp;rsquo;s unclear how the library will be used. Nonetheless will v0.4 be a significant release with a mostly stable API and most functionality being implemented.&lt;/p>
+&lt;p>Over the next five months we will fix the most pressing issues and make OpenMLS a usable MLS library for consumers to use. We are well aware that there is almost no experience with using MLS in a messaging product. (Cisco&amp;rsquo;s Webex is rolling out MLS for &lt;a href="https://www.btconferencing.com/downloads-library/services/webex-versions/t41/Webex_Latest_Channel_Customer_Monthly_Update_41.7.pdf">end-to-end encrypted video calls&lt;/a> as part of their &lt;a href="https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html">zero-trust initiative&lt;/a> right now.) The goal is therefore to offer a mostly stable API and complete feature set for consumers to start using it. However, we expect a significant feedback cycle to improve the APIs to make OpenMLS better suited for applications.&lt;/p></description></item><item><title>OpenMLS Performance</title><link>https://blog.openmls.tech/posts/2021-05-18-openmls-first-benchmarks/</link><pubDate>Tue, 18 May 2021 00:00:00 +0000</pubDate><guid>https://blog.openmls.tech/posts/2021-05-18-openmls-first-benchmarks/</guid><description>&lt;p>In this blog post, I explore how MLS&amp;rsquo; aspiration &lt;a href="https://datatracker.ietf.org/doc/charter-ietf-mls/">to be scalable&lt;/a> manifests itself in OpenMLS.&lt;/p>
 &lt;p>The charter in particular claims the following:&lt;/p>
 &lt;blockquote>
 &lt;p>Resource requirements have good scaling in the size of the group (preferably sub-linear)&lt;/p>

posts/2021-05-18-openmls-first-benchmarks/index.html

@@ -54,23 +54,23 @@
 We measure performance of a single message that is being sent and processed.
 Note that the processing time of subsequent messages is not significantly different from the first one.</li></ul><h2 id=results>Results<a hidden class=anchor aria-hidden=true href=#results>#</a></h2><p>You can find the raw data and some more graphs in the <a href=https://docs.google.com/spreadsheets/d/1nZv8lpT28JctDVo4ARBLZCKcIdvo-h8cIyN3_dIedFU>OpenMLS performance spreadsheet</a>.</p><p>All measurements were performed on a laptop with Arch Linux, an Intel Core i7-4900MQ @ 2.80GHz and 16 GB memory.</p><h3 id=group-setup>Group setup<a hidden class=anchor aria-hidden=true href=#group-setup>#</a></h3><p>As the following graph shows the time needed to create a group is linear in the number of participants added when creating the group.
 The blue line shows the actual measurements while the magenta one is a trend line showing the linear relation.
-This is what is to be expected because the performance is dominated by the creation of welcome messages, which have to be created for each member.</p><figure><a href=../images/group-creation.svg><img loading=lazy src=../images/group-creation.svg></a></figure><h3 id=join-group>Join group<a hidden class=anchor aria-hidden=true href=#join-group>#</a></h3><p>The performance of joining a group is linear in the group size because the information in the welcome message as well as the tree that is being processed when joining the group are linear in the number of group members.
+This is what is to be expected because the performance is dominated by the creation of welcome messages, which have to be created for each member.</p><figure><a href=../images/group-creation.svg><img loading=lazy src=../../images/group-creation.svg></a></figure><h3 id=join-group>Join group<a hidden class=anchor aria-hidden=true href=#join-group>#</a></h3><p>The performance of joining a group is linear in the group size because the information in the welcome message as well as the tree that is being processed when joining the group are linear in the number of group members.
 Note that it is not logarithmic because the tree needs to be constructed.
 This requires processing of each node in some way, which is linear in the group size.
-The blue line again shows the actual measurements while the magenta one is a trend line for the linear relation.</p><figure><a href=../../images/join.svg><img loading=lazy src=../images/join.svg></a></figure><h3 id=update>Update<a hidden class=anchor aria-hidden=true href=#update>#</a></h3><p>Sending and processing updates are both sub-linear in the number of group members because the number of computations depend on the height of the tree in the <em>base</em> case.</p><figure><a href=../../images/update.svg><img loading=lazy src=../images/update.svg></a></figure><p>In the case of a very sparse tree, which we have in the <em>bare</em> case because every leaf only processed the welcome message, the performance of sending an update however is linear in the group size.
+The blue line again shows the actual measurements while the magenta one is a trend line for the linear relation.</p><figure><a href=../../images/join.svg><img loading=lazy src=../../images/join.svg></a></figure><h3 id=update>Update<a hidden class=anchor aria-hidden=true href=#update>#</a></h3><p>Sending and processing updates are both sub-linear in the number of group members because the number of computations depend on the height of the tree in the <em>base</em> case.</p><figure><a href=../../images/update.svg><img loading=lazy src=../../images/update.svg></a></figure><p>In the case of a very sparse tree, which we have in the <em>bare</em> case because every leaf only processed the welcome message, the performance of sending an update however is linear in the group size.
 When creating a commit for an update proposal the sender has to include a path and refresh the private tree.
 The following two flamegraphs show the difference between the base and the bare case.
 While it doesn&rsquo;t show directly what&rsquo;s going on, it can be seen that in the base case (first flamegraph) the <code>new_with_keys</code> function requires a lot more time relative to the rest of the <code>replace_private_tree</code> function.
-This is a strong indicator for where to look for the differences.</p><p><figure><a href=../images/send-update-base.png><img loading=lazy src=../images/send-update-base.png></a></figure><figure><a href=../images/send-update-bare.png><img loading=lazy src=../images/send-update-bare.png></a></figure></p><p>Looking at a tree with 300 leaves for example we have to encrypt 299 times (for every other leaf) in the case of a bare tree.
+This is a strong indicator for where to look for the differences.</p><p><figure><a href=../images/send-update-base.png><img loading=lazy src=../../images/send-update-base.png></a></figure><figure><a href=../images/send-update-bare.png><img loading=lazy src=../../images/send-update-bare.png></a></figure></p><p>Looking at a tree with 300 leaves for example we have to encrypt 299 times (for every other leaf) in the case of a bare tree.
 In a fully updated tree however only 9 encryptions are necessary, one for each level of the tree.
 It is therefore expected that the performance of sending an update (with commit) in the bare case is linear in the group size.</p><h3 id=adding-a-user>Adding a user<a hidden class=anchor aria-hidden=true href=#adding-a-user>#</a></h3><p>Looking at the performance of adding a user and processing an add commit in the following graph we can again see the linear growth in relation to the number of group members.
 This is almost independent of the state of the tree.
-The operations appear to be slightly more expensive in a fully updated tree though.</p><figure><a href=../images/add.svg><img loading=lazy src=../images/add.svg></a></figure><h3 id=removing-a-user>Removing a user<a hidden class=anchor aria-hidden=true href=#removing-a-user>#</a></h3><p>Like updating, removing a user and processing a remove commit are linear in complexity in the base case as the following graph shows.
+The operations appear to be slightly more expensive in a fully updated tree though.</p><figure><a href=../images/add.svg><img loading=lazy src=../../images/add.svg></a></figure><h3 id=removing-a-user>Removing a user<a hidden class=anchor aria-hidden=true href=#removing-a-user>#</a></h3><p>Like updating, removing a user and processing a remove commit are linear in complexity in the base case as the following graph shows.
 Removing in a very sparse tree is significantly more expensive than in a fully updated tree.
 The reason is the same as for updating the tree.
-The remove information has to be encrypted to all other remaining participants in the tree.</p><figure><a href=../images/remove.svg><img loading=lazy src=../images/remove.svg></a></figure><h3 id=application-messages>Application messages<a hidden class=anchor aria-hidden=true href=#application-messages>#</a></h3><p>Sending and receiving application messages is essentially independent of the group size, as expected.
+The remove information has to be encrypted to all other remaining participants in the tree.</p><figure><a href=../images/remove.svg><img loading=lazy src=../../images/remove.svg></a></figure><h3 id=application-messages>Application messages<a hidden class=anchor aria-hidden=true href=#application-messages>#</a></h3><p>Sending and receiving application messages is essentially independent of the group size, as expected.
 Receiving the first message within an epoch has a small overhead compared to subsequent message as seen in the second graph.
-This should be negligible in practice though.</p><p><figure><a href=../images/application-message-send.svg><img loading=lazy src=../images/application-message-send.svg></a></figure><figure><a href=../images/application-message-receive.svg><img loading=lazy src=../images/application-message-receive.svg></a></figure></p><h2 id=analysis>Analysis<a hidden class=anchor aria-hidden=true href=#analysis>#</a></h2><p>First, the plain performance numbers tell us that the goal of the MLS charter of a protocol that scales well for large groups has been mostly.
+This should be negligible in practice though.</p><p><figure><a href=../images/application-message-send.svg><img loading=lazy src=../../images/application-message-send.svg></a></figure><figure><a href=../images/application-message-receive.svg><img loading=lazy src=../../images/application-message-receive.svg></a></figure></p><h2 id=analysis>Analysis<a hidden class=anchor aria-hidden=true href=#analysis>#</a></h2><p>First, the plain performance numbers tell us that the goal of the MLS charter of a protocol that scales well for large groups has been mostly.
 Depending on the state of the tree some operations might take longer than expected.
 However, this can be mitigated by the application ensuring that the tree is updated and shrunk regularly.
 Notably, the real world performance appears to be consistent with the theoretical expectations.</p><h2 id=technical-background>Technical background<a hidden class=anchor aria-hidden=true href=#technical-background>#</a></h2><p>The measurements are <em>not</em> done with any Rust benchmarking framework such as <a href=https://crates.io/crates/criterion>criterion</a>.