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[0x20];
private static final byte[] TOKEN_KEY = new byte[0x20];
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 across constants, thread-locals, and helper methods. Nesting is minimal and control flow is flat. Intent is clearly communicated through method names, comments, and the use of distinct keys for CID and token signing. Action granularity is appropriate, with one main operation per line in the core signing logic. Reading flow is natural, from key initialization to signing utilities. Minor deductions: the static initializer could be simplified, and the `sign` method's length adjustment logic introduces slight complexity. Overall, the code is concise, organized, and easy to follow.
Run 2
The code is well-structured and highly readable. It has a clear single responsibility (HMAC signing), organized into logical methods with descriptive names. The class is flat with minimal nesting, and each method performs one focused action. The static initialization of cryptographic keys is separated clearly, and the FastThreadLocal pattern is used appropriately to avoid contention. Comments explain non-obvious design decisions, enhancing clarity of intent. The code is concise without sacrificing readability, and the reading flow is natural: fields, initialization, helper methods, public API, private constructor. Minor deductions: the sign method does slightly more than one action (reset, update, doFinal, conditional copy), and the empty private constructor is a bit terse, but these are negligible. Overall, this is exemplary readable code.
Run 3
The code is highly readable with clear structure: constants, static initialization, thread-local declarations, helper methods, and public API are well-organized. Intent is explicit—comments explain why two keys are used, and method names like signCid/signToken clearly communicate purpose. Nesting is minimal; the only try/catch is flat and handles expected exceptions concisely. Code length is appropriate—no unnecessary lines, though the static initializer could be slightly more compact. Action granularity is strong: each line performs one logical operation, especially in sign() and newMac(). Reading flow is natural: top-down from constants to initialization to helpers to public methods. Minor deductions: the anonymous FastThreadLocal subclasses add minor noise, and the sign() method has a conditional array copy that could be a one-liner, but these are trivial. Overall, excellent readability and maintainability.
Run 1
Code Structure: Constants, key initialization, thread-local instances, and focused helper methods are logically organized. Nesting: Shallow try/catch and a single conditional keep complexity low. Clarity of intent: Descriptive names and the cryptographic separation comment clearly explain purpose; hexadecimal key lengths and input buffer consumption could be more explicit. Code length: Concise, with shared initialization and signing helpers avoiding substantial duplication. Action granularity: Each statement performs a distinct operation, making execution easy to trace. Reading flow: Consistent formatting and straightforward methods support natural reading, though public-facing signing methods follow their implementation helpers rather than introducing the interface first.
Run 2
Code Structure: Constants, key initialization, thread-local instances, shared helpers, and signing entry points are logically organized. Nesting: Shallow try/catch and a single conditional keep complexity low. Clarity of intent: Descriptive names and the key-separation comment clearly explain the purpose; hexadecimal key lengths and the input buffer's consumption are less explicit. Code length: Compact overall, with modest duplication in the two thread-local declarations that reinforces their separate roles. Action granularity: Nearly every line performs one action, making operations easy to follow. Reading flow: Consistent formatting and short methods support natural reading, although import grouping and a named key-length constant would improve polish.
Run 3
Code Structure: Constants, key initialization, thread-local instances, helpers, and public-facing signing methods are logically grouped. Nesting: Shallow, limited to anonymous classes, a try/catch, and one conditional. Clarity of intent: Descriptive names and the key-separation comment clearly explain the design; hexadecimal key lengths and the input buffer's consumption are less explicit. Code length: Concise overall, with minor duplication in the two thread-local declarations. Action granularity: Each statement performs a distinct operation, making execution easy to follow. Reading flow: Natural progression from configuration to implementation and entry points, though tighter import formatting and the placement of signing entry points after helpers slightly reduce scanability.