IKM Length & NSK In KEM: Issues And Solutions

Introduction

Hey guys! Let's dive into a crucial discussion surrounding Key Encapsulation Mechanisms (KEMs), specifically addressing the inflexibility in Input Keying Material (IKM) length and its implications on the size of the secret key (Nsk). This issue, raised within the hpkewg and hpke-pq discussion categories, touches upon the current draft specifications where the required length of the IKM is rigidly set to equal the size of the secret key, which is 64 bytes. This constraint might throw some users for a loop and introduces some interesting challenges, especially when considering protocols like MLS (Messaging Layer Security) and their reliance on specific Key Derivation Functions (KDFs). We'll explore the problem, understand the potential roadblocks, and then break down the proposed solutions to make sure we're all on the same page.

The current draft's insistence on a fixed IKM length (len(ikm) = Nsk = 64) represents a notable shift from existing KEMs, which typically only mandate that the IKM's length be greater than or equal to the secret key size (len(ikm) ≥ Nsk). This change, while seemingly minor, can have cascading effects on how KEMs are integrated into higher-level protocols and systems. One immediate consequence is the potential forcing of MLS, as it's currently written, to utilize HKDF-SHA512 from the existing KDF set. This creates a lower bound that might not be ideal for all use cases, potentially limiting flexibility and efficiency. The core of the issue lies in balancing security considerations with practical implementation constraints. A rigid IKM length requirement can simplify certain aspects of the KEM design and analysis, but it can also impose unnecessary burdens on applications that might prefer to use different IKM lengths or KDFs. For instance, if an application has a naturally shorter IKM available, padding it to 64 bytes might introduce complexity and potential vulnerabilities. Conversely, if an application prefers to use a different KDF with a different output size, the fixed IKM length could create an impedance mismatch. The discussion, therefore, revolves around finding the sweet spot that ensures robust security without unduly restricting the flexibility of KEM implementations and their integration into diverse cryptographic systems.

We'll break down why this is a big deal, especially for things like MLS, and then dig into the solutions that have been put on the table. We aim to clarify the options and weigh their pros and cons so that we can choose the best path forward for KEM implementations. Let's get started!

The Problem: IKM Length Inflexibility

The main gripe here is that the current draft says the IKM (Input Keying Material) needs to be exactly 64 bytes, matching the size of the secret key (Nsk). Now, existing KEMs (Key Encapsulation Mechanisms) are more chill about this – they usually just say the IKM has to be at least as long as the Nsk. This strict requirement can catch folks off guard and cause some headaches. Think of it like this: imagine you're using a password that has to be exactly 12 characters long. What if you have a super secure 10-character password you really like? You'd have to add extra characters just to meet the requirement, which feels a bit silly, right?

Specifically, the inflexibility in IKM length can present challenges in several scenarios. First, protocols like MLS, which are designed to provide secure group communication, might be forced to adopt specific KDFs, such as HKDF-SHA512, simply to comply with the 64-byte IKM requirement. This restriction limits the flexibility of MLS and potentially hinders its ability to adapt to different security needs and performance profiles. Furthermore, applications that naturally have shorter IKMs might be compelled to pad them to 64 bytes, introducing unnecessary complexity and potentially creating vulnerabilities if the padding scheme is not carefully designed. For example, if a simple zero-padding scheme is used, an attacker might be able to exploit this to reduce the entropy of the IKM. On the other hand, applications that prefer to use KDFs with different output sizes might encounter an impedance mismatch, requiring additional processing steps to reconcile the IKM length with the KDF's requirements. This not only increases the computational overhead but also adds to the complexity of the system, making it more prone to errors and security flaws. The core issue is that a one-size-fits-all approach to IKM length can be overly restrictive and might not be optimal for all use cases.

For one, the inflexibility forces MLS (Messaging Layer Security), as it's written now, to use HKDF-SHA512 from its existing set of KDFs. That's a needlessly tight constraint. It's like saying you have to use a specific wrench for every bolt, even if another one fits just fine and might even be easier to use! This limitation can impact performance and future flexibility. We want to avoid unnecessary lower bounds that might box us in later. We need a solution that gives us wiggle room without compromising security. So, what options do we have?

Proposed Solutions

Okay, so we've established there's a bit of a snag with the rigid IKM length. But don't worry, some smart cookies have already cooked up a few potential solutions. Let's break them down:

1. Accept the Breaking Change

This is the most straightforward, albeit potentially disruptive, option. It essentially means sticking with the current draft's requirement of len(ikm) = Nsk = 64. This means developers and implementers would need to adapt their systems to this new constraint. It’s the equivalent of saying,