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 initialValue() {
return newMac(CID_KEY);
}
};
private static final FastThreadLocal<Mac> TOKEN_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac initialValue() {
return newMac(TOKEN_KEY);
}
};
private static Mac newMac(byte[] key) {
try {
SecretKeySpec keySpec = new SecretKeySpec(key, ALGORITHM);
Mac mac = Mac.getInstance(ALGORITHM);
mac.init(keySpec);
return mac;
} catch (NoSuchAlgorithmException | InvalidKeyException exception) {
throw new IllegalStateException(exception);
}
}
private static ByteBuffer sign(Mac mac, ByteBuffer input, int outLength) {
mac.reset();
mac.update(input);
byte[] signBytes = mac.doFinal();
if (signBytes.length != outLength) {
signBytes = Arrays.copyOf(signBytes, outLength);
}
return ByteBuffer.wrap(signBytes);
}
static ByteBuffer signCid(ByteBuffer input, int outLength) {
return sign(CID_MACS.get(), input, outLength);
}
static ByteBuffer signToken(ByteBuffer input, int outLength) {
return sign(TOKEN_MACS.get(), input, outLength);
}
private Hmac() { }
}
Run 1
The code is highly readable. Structure is clear: constants, keys, thread locals, helper, public methods, private constructor. Nesting is minimal (one try-catch). Intent is well-explained with a helpful comment about key separation. Length is concise. Each line performs one action, and reading flow is natural. Minor deductions: exception handling is slightly verbose, and the FastThreadLocal initialValue pattern adds a bit of boilerplate, but overall the code is easy to follow and maintain.
Run 2
The code is logically structured with clear separation of concerns: constants, initialization, thread-local setup, and signing methods. Nesting is minimal — only one level in the static initializer and try-catch blocks. The intent is well documented, especially the security rationale for separate keys. Method names (`signCid`, `signToken`, `newMac`) clearly describe their purposes. Code length is concise without sacrificing clarity; the class does one thing well. Each line performs a single logical action, enhancing readability. The reading flow is natural: static fields, initialization, helper methods, public API, then private constructor. Minor deductions: the `sign` method could be slightly clearer with intermediate variables, and the empty private constructor could benefit from a comment explaining the utility-class pattern. Overall, the code is highly readable for a cryptographic utility class.
Run 3
The code is well-structured and highly readable. It uses clear naming, concise methods, and logical separation of concerns. The static initialization of keys and thread-local Mac instances is sensible. Comments explain non-obvious design decisions. Each method performs a single action, and nesting is minimal. Minor deductions: exception handling in a single catch block is fine, but the sign method could be slightly clearer about why the key length check exists. Overall, very clean code with good documentation and flat structure.
Run 1
Code Structure: Logically organized into key initialization, thread-local MAC instances, shared helpers, and purpose-specific entry points. Nesting: Shallow, with only straightforward initialization, exception handling, and one conditional. Clarity of intent: Descriptive names and the key-separation comment clearly explain the purpose; however, input buffer consumption and output truncation or padding are not documented. Code length: Concise overall, with minor duplication in the two thread-local declarations. Action granularity: Each statement performs a single clear action. Reading flow: Natural progression from configuration to initialization to implementation and public-facing operations, with consistent formatting and spacing.
Run 2
Code Structure: Constants, key initialization, thread-local MAC instances, shared helpers, and signing entry points are logically organized. Nesting: Shallow try/catch and a single conditional keep control flow easy to follow. Clarity of intent: Descriptive names and the key-separation comment explain the purpose well; however, input buffer consumption and truncation or zero-padding behavior are not documented. Code length: Compact methods and shared helpers avoid unnecessary repetition, with only minor duplication in thread-local initialization. Action granularity: Each statement performs a distinct operation, making execution easy to trace. Reading flow: Consistent formatting and straightforward delegation support natural reading, though spacing between the package declaration and imports would improve presentation.
Run 3
Code Structure: Well-organized constants, key initialization, thread-local MAC instances, shared helpers, and signing entry points. Nesting: Shallow, limited to initialization overrides, a try/catch, and one conditional. Clarity of intent: Descriptive names and a useful comment clearly explain the separation of CID and token signing; input buffer consumption and output truncation or padding are less explicit. Code length: Concise, with shared helpers avoiding substantial duplication. Action granularity: Each statement performs a distinct action, making operations easy to follow. Reading flow: Consistent formatting and logical grouping support natural top-to-bottom reading, though the lack of spacing after the package declaration is a minor presentation issue.