Truncate blog posts on /blog/

_includes/post.html

@@ -17,12 +17,17 @@
   </header>
 
   <div class="post-content e-content" itemprop="articleBody">
-    {{ post.content }}
+    <!-- {%- if include.show_summary == true -%} -->
+      {{ post.content | split: '<!--more-->' | first | markdownify }}
+      <p><a href="{{ post.url | relative_url }}">Read more…</a></p>
+    <!-- {%- else -%} -->
+      {{ post.content }}
+    <!-- {%- endif -%} -->
   </div>
 
   {%- if site.disqus.shortname -%}
     {%- include disqus_comments.html -%}
   {%- endif -%}
 
   <a class="u-url" href="{{ post.url | relative_url }}" hidden></a>
-</article>
+</article>

_posts/2024-04-09-key-to-simplicity-squeezing-the-hassle-out-of-encryption-key-recovery.md

@@ -12,19 +12,19 @@ author-github: imperiopolis
 
 Cryptography transforms the impossible task of safeguarding extensive data transmitted and stored across numerous systems and networks into the simpler task of securing a small singular key in one location. It is a magical thing. However, as services increasingly adopt end-to-end encryption for privacy features, this single small key has emerged as something with challenges and problems of its own.
 
-One of the most notable challenges is ensuring that someone (but only that someone!) has _continued_ access to the encryption keys protecting their data, regardless of whether they reinstall an app, lose their phone, or encounter any of the other myriad pitfalls of life. 
+One of the most notable challenges is ensuring that someone (but only that someone!) has _continued_ access to the encryption keys protecting their data, regardless of whether they reinstall an app, lose their phone, or encounter any of the other myriad pitfalls of life.
 
 Unfortunately, the default approach to these problems is often to place the burden directly onto the user by requiring them to manage a backup of their secret key. These keys are too long to memorize and are challenging for users to store securely. This complexity becomes especially evident when users need to input their key material on a new device, leading some to opt for less secure alternatives instead of navigating the secure platform.
-
+<!--more-->
 ## Unlocking the key conundrum
 
 Various solutions have been proposed to address this issue. In the web3/crypto space, seed phrases offer a slight simplification by representing a key as a series of words, but they still require users to manage lengthy and unmemorable strings. Passkeys prove more compelling by eliminating the need for users to remember key material, but introduce their own UX challenges when storing and transferring this material across devices, and their own security challenges when considering how they are backed up themselves.
 
 The field of “password based encryption” aimed to solve this issue by transforming short user-memorable passwords into encryption keys through iterative hashing or the like, such that an encryption key can always be recovered from something that a user can remember. However, regardless of how a key derivation function is tuned, these systems have proven very vulnerable to attackers that [employ dictionary or brute force attacks to make guesses](https://www.nytimes.com/2014/08/06/technology/russian-gang-said-to-amass-more-than-a-billion-stolen-internet-credentials.html) until they too are able to recover the correct key.
 
-Some of the most promising solutions to date leverage secure hardware, such as programmable Hardware Security Modules (HSMs). The innovation here is that secure hardware can be used to limit an attacker’s ability to make guesses, so that short user-memorable inputs can be transformed into encryption keys without the same risks of brute forcing or dictionary attacks that came with traditional password based encryption. 
+Some of the most promising solutions to date leverage secure hardware, such as programmable Hardware Security Modules (HSMs). The innovation here is that secure hardware can be used to limit an attacker’s ability to make guesses, so that short user-memorable inputs can be transformed into encryption keys without the same risks of brute forcing or dictionary attacks that came with traditional password based encryption.
 
-Indeed, companies like Apple and WhatsApp [use programmable HSMs in this way](https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/) to enable end-to-end backup of keys protecting some user data. Their interface typically involves logging into an account (using an Apple ID or phone number) and entering a 6-digit PIN. This PIN is indirectly used to protect a secret, and the HSM prevents an attacker (including the operator) from brute forcing. Signal’s [Secure Value Recovery](https://signal.org/blog/secure-value-recovery/) was an initial proof of concept for this type of system, but relies on a weaker version of secure hardware (Intel’s SGX) to provide a simplified PIN based user interface using a similar underlying mechanism. 
+Indeed, companies like Apple and WhatsApp [use programmable HSMs in this way](https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/) to enable end-to-end backup of keys protecting some user data. Their interface typically involves logging into an account (using an Apple ID or phone number) and entering a 6-digit PIN. This PIN is indirectly used to protect a secret, and the HSM prevents an attacker (including the operator) from brute forcing. Signal’s [Secure Value Recovery](https://signal.org/blog/secure-value-recovery/) was an initial proof of concept for this type of system, but relies on a weaker version of secure hardware (Intel’s SGX) to provide a simplified PIN based user interface using a similar underlying mechanism.
 
 However, while relying on hardware security reduces user burden, it assumes the inherent security of a specific set of hardware and firmware. The safety of your secrets becomes contingent on the security of the hardware used to recover them, which can lead to challenges in keeping up with evolving hardware vulnerabilities. Moreover, secure hardware is often performance-constrained, outdated, and costly, posing sustainability issues at scale.
 
@@ -51,7 +51,7 @@ The most straightforward version of standard HSM based key recovery looks like t
 4. In the future, the HSM will return the key to the client if it can present the correct PIN.
 5. The HSM uses the guess counter to limit the total number of possible PIN attempts a client gets.
 
-Obviously, if the HSM is compromised, all user data is compromised along with it. For Juicebox, our initial challenge was to sever this link between the security of a user secret and the security of the single server where it is stored. 
+Obviously, if the HSM is compromised, all user data is compromised along with it. For Juicebox, our initial challenge was to sever this link between the security of a user secret and the security of the single server where it is stored.
 
 The first step is to allow for distributing trust beyond a single organization or HSM vendor. Juicebox employs a strategy of distributing secrets across _**n**_ independent services, each implementing the _**Juicebox Protocol**_, and retrieving them from a _**threshold**_ set where _**n >= threshold**_. We refer to each of these services as a _**realm**_.
 
@@ -71,11 +71,11 @@ Here's how it works:
 
 ![OPRF Evaluation](/assets/images/oprf-evaluation.png)
 
-This final result can be used as a recoverable encryption key. 
+This final result can be used as a recoverable encryption key.
 
 However, when you're dealing with _**threshold**_ realms, controlled by any number of operators, this model becomes impractical. Executing an OPRF evaluation for each realm (and calculating _**threshold**_ independent results) incurs significant performance costs. Moreover, if one realm's private key is compromised, it undermines trust in that realm for all users.
 
-Enter [Threshold OPRFs (T-OPRFs)](https://eprint.iacr.org/2017/363.pdf) – a variant on the traditional OPRF specifically designed to solve both of these problems by combining secret sharing with OPRFs. Each realm's private key becomes a unique share of a random root private key created on the client during secret storage. This mathematical association of realm private keys enables us to optimize the operation to a single T-OPRF evaluation across the entire threshold of realms. 
+Enter [Threshold OPRFs (T-OPRFs)](https://eprint.iacr.org/2017/363.pdf) – a variant on the traditional OPRF specifically designed to solve both of these problems by combining secret sharing with OPRFs. Each realm's private key becomes a unique share of a random root private key created on the client during secret storage. This mathematical association of realm private keys enables us to optimize the operation to a single T-OPRF evaluation across the entire threshold of realms.
 
 By creating shares of a single blinded input, and later reconstructing the blinded result shares received from each realm, we can reduce an entire threshold set to a single shared result. Additionally, since this approach requires the client to generate the associated keys for each realm, the client can also rotate those keys anytime it updates the stored secret.
 
@@ -108,7 +108,7 @@ There's one last piece of information that realms have the chance to manipulate
 
 ### Trusting deliberately
 
-The new paradigm we've established gives us the opportunity to look at ways we could supplement HSM realms in a _**threshold**_ set with additional realms that are scalable and cost-effective. 
+The new paradigm we've established gives us the opportunity to look at ways we could supplement HSM realms in a _**threshold**_ set with additional realms that are scalable and cost-effective.
 
 Juicebox supports two basic types of realm:
 
@@ -123,7 +123,7 @@ A simple configuration could consist of one hardware realm hosted by one organiz
 
 ### Hardware hurdles
 
-In traditional setups using HSMs, data is stored within the limited persistent memory of these specialized devices. However, due to the constrained storage capacity of HSMs, storing a large dataset entirely within them is often impractical or even impossible, and any hardware failure can result in a loss of user data without the use of complicated replication schemes. 
+In traditional setups using HSMs, data is stored within the limited persistent memory of these specialized devices. However, due to the constrained storage capacity of HSMs, storing a large dataset entirely within them is often impractical or even impossible, and any hardware failure can result in a loss of user data without the use of complicated replication schemes.
 
 On the other hand, storing sensitive data in a traditional database would negate the benefits of HSMs entirely. Even if the records were stored in encrypted form, an HSM could not reliably distinguish an old version of a record from the latest version, thereby allowing an adversary with access to the hardware to roll back the state. Preventing roll-back attacks is crucial to ensuring realms cannot deny access to secrets, while maintaining strict limits on attacker guesses before secret material becomes inaccessible.
 
@@ -135,7 +135,7 @@ Juicebox’s implementation enables:
 * **Logarithmic Performance:** Tree operations' performance scales logarithmically with the number of records in the tree, a significant improvement over linear lookup key approaches.
 * **Dynamic Partitioning:** The overall dataset can be dynamically partitioned across multiple trees, facilitating seamless scaling up or down with fast and inexpensive repartitioning.
 * **Parallelized Operations:** Reads from each tree can be fully parallelized, even during ongoing writes, allowing HSMs to process continuous requests to mutate a tree without waiting for results to reach storage.
-* **Reduced Storage Cost:** Tree nodes can be stored and cached freely on an untrusted, non-transactional storage system, reducing storage costs by enabling the use of highly scalable cloud storage solutions such as Bigtable. 
+* **Reduced Storage Cost:** Tree nodes can be stored and cached freely on an untrusted, non-transactional storage system, reducing storage costs by enabling the use of highly scalable cloud storage solutions such as Bigtable.
 
 Juicebox also employs an authenticated consensus protocol to recover from hardware failures, wherein HSMs validate freshness and authenticity on top of commodity hardware performing more [traditional consensus](https://en.wikipedia.org/wiki/Consensus_(computer_science)). The ability to authenticate the entire Merkle-Radix tree with a single hash allows this consensus protocol to reach agreement on just a small amount of metadata as the tree evolves, making operations simpler and more efficient.
 
@@ -149,6 +149,6 @@ To address these concerns, each realm in our system logs recovery attempts – s
 
 Juicebox’s [source code](https://github.com/juicebox-systems) is now available, and we encourage you to read our [Juicebox Protocol](/assets/whitepapers/juiceboxprotocol_revision7_20230807.pdf) and [Merkle-Radix tree](/assets/whitepapers/merkleradix_revision1_20230629.pdf) whitepapers for more detailed information. If you’re ready to try it out, a [demo](https://demo.juicebox.xyz/) is available, configured for our sandbox realms.
 
-Juicebox represents our earnest effort to tackle the challenges of end-to-end encryption key recovery with pragmatism and care. We've combined proven techniques like Threshold OPRFs and Merkle-Radix trees to create a solution that prioritizes security without sacrificing user experience. Our [doors are open to feedback](mailto:[email protected]) and collaboration as we continue to refine and enhance what we’ve created. 
+Juicebox represents our earnest effort to tackle the challenges of end-to-end encryption key recovery with pragmatism and care. We've combined proven techniques like Threshold OPRFs and Merkle-Radix trees to create a solution that prioritizes security without sacrificing user experience. Our [doors are open to feedback](mailto:[email protected]) and collaboration as we continue to refine and enhance what we’ve created.
 
-Juicebox was created by Alex Bochannek, Simon Fell, Moxie Marlinspike, Diego Ongaro, Daniela Perlein, and Nora Trapp. The project received valuable feedback from Trevor Perrin and was audited by NCC in June 2023.
+Juicebox was created by Alex Bochannek, Simon Fell, Moxie Marlinspike, Diego Ongaro, Daniela Perlein, and Nora Trapp. The project received valuable feedback from Trevor Perrin and was audited by NCC in June 2023.

_posts/2024-08-14-running-a-hsm-realm.md

@@ -23,7 +23,7 @@ design, as it requires multiple HSMs, physical servers to host them, and cloud
 resources to provide its significantly higher level of security. Additionally,
 these realms require a lengthy initialization and deployment process that
 software realms avoid.
-
+<!--more-->
 As you make your way through this blog post, you may want to reference the
 useful information located in the [HSM realm
 readme](https://github.com/juicebox-systems/juicebox-hsm-realm/blob/main/README.md)

pages/blog.md

@@ -5,8 +5,8 @@ permalink: /blog/
 ---
 
 {% for post in site.posts %}
-  {%- include post.html -%}
+  {%- include post.html show_summary=true -%}
   {%- if post != site.posts.last -%}
     <div class='post-divider'></div>
   {%- endif -%}
-{% endfor %}
+{% endfor %}