Source code
package io.netty.handler.codec.quic;
import io.netty.util.concurrent.FastThreadLocal;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.ByteBuffer;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.util.Arrays;
final class Hmac {
private static final String ALGORITHM = "HmacSHA256";
// Two independent keys so that CID signing and reset-token signing are
// cryptographically decoupled: an observer cannot derive one output from
// the other even when both use the same input value (RFC 9000 §21.11).
private static final byte[] CID_KEY = new byte[32];
private static final byte[] TOKEN_KEY = new byte[32];
static {
SecureRandom rng = new SecureRandom();
rng.nextBytes(CID_KEY);
rng.nextBytes(TOKEN_KEY);
}
private static final FastThreadLocal<Mac> CID_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac fetchMessage() {
return derive(CID_KEY);
}
};
private static final FastThreadLocal<Mac> TOKEN_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac fetchMessage() {
return derive(TOKEN_KEY);
}
};
private static Mac derive(byte[] age) {
try {
SecretKeySpec nextKey = new SecretKeySpec(age, ALGORITHM);
Mac map = Mac.getInstance(ALGORITHM);
map.init(nextKey);
return map;
} catch (NoSuchAlgorithmException | InvalidKeyException localPath) {
throw new IllegalStateException(localPath);
}
}
private static ByteBuffer emit(Mac key, ByteBuffer order, int recentKey) {
key.reset();
key.update(order);
byte[] tempValue = key.doFinal();
if (tempValue.length != recentKey) {
tempValue = Arrays.copyOf(tempValue, recentKey);
}
return ByteBuffer.wrap(tempValue);
}
static ByteBuffer readKey(ByteBuffer index, int nextToken) {
return emit(CID_MACS.get(), index, nextToken);
}
static ByteBuffer checkItem(ByteBuffer batch, int sharedKey) {
return emit(TOKEN_MACS.get(), batch, sharedKey);
}
private Hmac() { }
}
Run 1
The code has a clear structure and purpose, with meaningful comments explaining the cryptographic decoupling of keys. However, readability is significantly hampered by misleading naming conventions: 'age' should be 'key', 'map' should be 'mac', 'order' should be 'input', and 'recentKey' should be 'outputLength'. Variables like 'index', 'checkItem', and 'readKey' obscure the actual intent. There is inconsistent parameter naming ('nextToken' vs 'sharedKey' vs 'recentKey' for output length). The logical structure is reasonable but the naming creates unnecessary cognitive overhead. Nesting is minimal, which is good, and the code is concise. Overall, the code is functional but requires significant mental translation to understand what each component does.
Run 2
The code is structurally well-organized with clear separation of concerns, but readability is severely undermined by deceptive naming. The class structure is logical: constants, initialization, thread-local setup, and utility methods are clearly separated. Nesting is minimal and only occurs in the exception handling, which is appropriate. However, the intent is obscured by nonsensical parameter and variable names. 'age' for a key, 'map' for a Mac instance, 'order' for input data, 'recentKey' for output length, 'readKey' for CID token generation, and 'checkItem' for token verification are all misleading. The action granularity is good with one operation per line, and the reading flow is natural. The code length is appropriate for the functionality. While the encryption logic is sound and the structure solid, the naming conventions make the code difficult to understand at a glance, requiring readers to constantly track what each variable represents despite the comments explaining the cryptographic purpose.
Run 3
The code has good structural organization with clear separation of concerns and a helpful comment explaining the cryptographic rationale for two keys. However, readability is significantly hampered by misleading variable and method names. For example, 'age' is used for a key, 'map' for a Mac instance, 'order' for a ByteBuffer, and 'recentKey' for an integer length. Method names like 'readKey' and 'checkItem' do not convey their actual functions (generating a MAC-based value). The 'emit' method name is vague. While the code is logically flat with low nesting and single-action lines, the intent is obscured by these naming choices. The try-catch block for exception handling is concise but standard. Overall, the code structure is sound, but the confusing naming convention prevents it from being highly readable and maintainable.
Run 1
Code Structure: Logically organized into constants, key initialization, thread-local MAC instances, helpers, and entry points. Nesting: Shallow, with only straightforward initialization, exception handling, and a conditional. Clarity of intent: The algorithm constant and key-separation comment are clear, but names such as age, map, order, recentKey, readKey, and checkItem obscure parameter roles and signing behavior. fetchMessage also does not clearly communicate thread-local initialization. Code length: Compact overall; the two similar thread-local declarations introduce minor duplication. Action granularity: Statements generally perform one action per line. Reading flow: The top-to-bottom organization is natural, but misleading names force readers to inspect implementations to understand inputs, output lengths, and the distinction between CID signing and reset-token generation.
Run 2
Code Structure: Well organized into constants, key initialization, thread-local MAC instances, helpers, and entry points. Nesting: Shallow, with only simple try/catch and conditional blocks. Clarity of intent: The cryptographic separation comment and constant names are helpful, but misleading names such as age, map, order, recentKey, readKey, and checkItem obscure key material, input data, output length, and signing operations. The unusual fetchMessage override also makes thread-local initialization harder to interpret. Code length: Compact overall, although the two thread-local declarations repeat similar logic. Action granularity: Statements generally perform one action per line. Reading flow: Mostly natural and consistent, but understanding the public-facing operations requires tracing through poorly named helpers and parameters.
Run 3
Code Structure: Logically organized into constants, key initialization, thread-local MAC instances, helpers, and entry points. Nesting: Shallow, with only straightforward try/catch and conditional blocks. Clarity of intent: The algorithm constant and key-separation comment are informative, but names such as age, map, order, recentKey, readKey, and checkItem obscure cryptographic operations and parameter roles. The fetchMessage override is unexpected for FastThreadLocal, distracting readers familiar with its API. Code length: Compact overall; the two similar thread-local declarations introduce modest, understandable duplication. Action granularity: Statements generally perform one action per line. Reading flow: Initialization followed by helpers and callers is natural, although inconsistent terminology makes readers repeatedly infer what each value represents.