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 well-structured and highly readable. It has a clear, logical organization with constants, initialization, thread-local setup, and methods grouped logically. Nesting is minimal, with only one level in the catch block and anonymous classes. Intent is clearly conveyed through descriptive names like CID_KEY, TOKEN_KEY, and signCid/signToken, and the comment explaining key separation adds valuable context. Code is concise with no unnecessary lines. Each line performs a single action, improving clarity. Reading flow is natural, from setup to utility methods to public API. Minor deductions: duplicate thread-local blocks could be extracted, and the try/catch slightly interrupts flow, but overall excellent readability.
Run 3
The code is well-structured and highly readable. It follows a clear logical organization: constants, key initialization, thread-local Mac instances, helper methods, and public API methods. Nesting is minimal—only a single try-catch block and anonymous inner classes. The intent is clearly documented with a concise comment explaining the rationale for two independent keys. Code length is appropriate, with no unnecessary verbosity. Action granularity is excellent; each line performs a single logical operation, such as resetting the Mac, updating it, or wrapping bytes. Reading flow is natural: the static block initializes keys, then Mac instances are defined, followed by the signing logic and public methods. The only minor drawback is the custom MAC length handling, which could be slightly clearer, but overall this is a well-crafted, maintainable utility class.
Run 1
Code Structure: Constants, key initialization, thread-local state, helpers, and public-facing operations are logically grouped. Nesting: Shallow methods and a single conditional keep complexity low; anonymous classes add only modest nesting. Clarity of intent: Descriptive names and the key-separation comment clearly explain the purpose. However, sign() does not document that it consumes the input buffer or that Arrays.copyOf pads outputs when outLength exceeds the digest length. Code length: Compact and appropriately factored, with minor duplication in the thread-local declarations. Action granularity: Each statement performs one clear action, making operations easy to follow. Reading flow: The progression from configuration through initialization to signing is natural, though import spacing and ordering could be polished.
Run 2
Code Structure: Logically separates key initialization, thread-local MAC creation, shared signing logic, and purpose-specific entry points. Nesting: Shallow, with only a simple conditional and try/catch. Clarity of intent: Descriptive names and a useful security comment explain the independent keys; however, sign does not document that it advances the input buffer or that larger output lengths cause zero-padding. Code length: Concise, with shared helpers avoiding duplicated signing and initialization logic; the two thread-local declarations are reasonable repetition. Action granularity: Statements generally perform one action per line. Reading flow: Natural progression from configuration and state to helpers and public-facing operations, though import grouping and spacing could be slightly more polished.
Run 3
Code Structure: Constants, key initialization, thread-local MAC instances, shared helpers, and signing entry points are logically organized. Nesting: Shallow control flow makes methods easy to follow; anonymous classes add little complexity. Clarity of intent: Descriptive names and the key-separation comment clearly explain the purpose, although input buffer consumption and output truncation or padding are not documented. Code length: Concise, with shared helpers avoiding substantial duplication; the two thread-local initializers are reasonably repetitive. Action granularity: Each statement generally performs one clear action. Reading flow: Consistent formatting and straightforward delegation provide a natural progression from setup to signing operations.