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 well-structured with clear separation of concerns: static keys, thread-local Mac instances, and signing logic are logically organized. Nesting is minimal—only one level in the try/catch block and anonymous FastThreadLocal implementations. Intent is clearly communicated through descriptive method names (signCid, signToken) and a helpful comment explaining the cryptographic rationale. Code length is appropriate; no unnecessary verbosity. Action granularity is excellent, with one logical action per line, especially in the sign method. Reading flow is natural: constants, initialization, factory method, core logic, then public API. Minor improvements could include extracting the anonymous FastThreadLocal classes into named static subclasses for slightly better readability, and the sign method's resizing logic could be marginally clearer. Overall, this is highly readable code.
Run 2
The code is highly readable with excellent structure and clear intent. It has a single-purpose class with well-named constants that explain the decoupling rationale in a comment. Static initialization is clean, and thread-local patterns are compact. Nesting is minimal, and each method performs one logical action. The only deductions are for minor verbosity in exception handling and slight redundancy in the sign method's byte array copy. Overall, the flow is natural and the code requires little cognitive effort to understand.
Run 3
The code is well-structured with clear separation of concerns: constants, static initialization, thread-local setup, helper methods, and public API. It remains flat with no nested control flow, making it easy to follow. The comment explaining why two keys are used adds valuable context without being verbose. Method names like `signCid` and `signToken` clearly convey intent, and the `newMac` helper avoids duplication. Each line performs a single logical action, improving readability. The only minor deductions are the slightly unclear interaction between `sign` and its caller regarding output length handling, and the anonymous `FastThreadLocal` subclasses add some boilerplate though they remain straightforward. Overall, the code is concise, purposeful, and maintainable.
Run 1
Code Structure: Logically organized into key initialization, thread-local MAC creation, shared signing logic, and purpose-specific entry points. Nesting: Shallow; anonymous classes and a simple try/catch add little complexity. Clarity of intent: Descriptive names and the key-separation comment clearly explain the design, though input buffer consumption and output resizing behavior are not documented. Code length: Concise, with shared helpers avoiding substantial duplication; the two thread-local definitions introduce minor repetition. Action granularity: Each statement performs a focused action, with no crowded multi-operation lines. Reading flow: Natural progression from configuration to implementation to public-facing package methods, supported by consistent spacing and formatting.
Run 2
Code Structure: Constants, key initialization, thread-local MAC instances, shared helpers, and signing entry points are logically organized. Nesting: Shallow nesting with only a try/catch and a simple conditional keeps the code easy to follow. Clarity of intent: Descriptive names and the explanatory comment clearly communicate the separation between CID and token signing. However, input buffer consumption and output truncation or zero-padding are implicit. Code length: Concise overall; the two similar thread-local declarations introduce minor but understandable duplication. Action granularity: Each statement performs a focused action, without compressed multi-action lines. Reading flow: Consistent formatting and straightforward delegation provide a natural progression from setup to implementation to public-facing operations.
Run 3
Code Structure: Constants, key initialization, thread-local MAC instances, 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 cryptographic separation comment clearly explain the purpose; input buffer consumption and output truncation or padding are less explicit. Code length: Compact methods and shared helpers avoid unnecessary repetition, although the thread-local initializers have minor duplication. Action granularity: Each statement performs one clear operation. Reading flow: Consistent formatting and straightforward delegation make reading natural; brief documentation of signing side effects would improve it further.