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 initial() {
return new2(CID_KEY);
}
};
private static final FastThreadLocal<Mac> TOKEN_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac initial() {
return new2(TOKEN_KEY);
}
};
private static Mac new2(byte[] key) {
try {
SecretKeySpec key2 = new SecretKeySpec(key, ALGORITHM);
Mac mac = Mac.getInstance(ALGORITHM);
mac.init(key2);
return mac;
} catch (NoSuchAlgorithmException | InvalidKeyException exc) {
throw new IllegalStateException(exc);
}
}
private static ByteBuffer sig(Mac mac, ByteBuffer inp, int out) {
mac.reset();
mac.update(inp);
byte[] sign2 = mac.doFinal();
if (sign2.length != out) {
sign2 = Arrays.copyOf(sign2, out);
}
return ByteBuffer.wrap(sign2);
}
static ByteBuffer sign(ByteBuffer inp2, int out2) {
return sig(CID_MACS.get(), inp2, out2);
}
static ByteBuffer sign2(ByteBuffer inp3, int out3) {
return sig(TOKEN_MACS.get(), inp3, out3);
}
private Hmac() { }
}
Run 1
The code is generally readable with a clear structure: constants, static initialization, thread-locals, helper methods, and public API. The comments explain the cryptographic rationale for two separate keys. Nesting is minimal, and each method has a single responsibility. However, readability is reduced by unclear naming: 'Hmac' is too generic, 'new2' is cryptic, and 'sign2', 'inp2', 'out2', 'inp3', 'out3' are poor names that don't convey intent. The method 'sig' takes a 'Mac' parameter but also resets and updates it, which slightly obscures the flow. The static initialization of keys is straightforward but could be extracted into a helper method. Overall, the code is maintainable but would benefit from more descriptive naming conventions.
Run 2
The code is generally well-structured and readable. It has a clear logical organization, flat nesting, and concise methods. Each line generally performs one action, and the reading flow is natural. The use of explanatory comments helps clarify intent, particularly regarding the two independent keys. However, minor improvements could enhance readability: the method and variable names with numeric suffixes (new2, inp2, out2, sign2) are slightly confusing, and the abbreviation of 'signature' to 'sig' and 'input' to 'inp' reduces clarity. The static initialization block is straightforward, but the exception handling in new2 could be slightly more explicit. Overall, the code is clean and maintainable with only small readability drawbacks.
Run 3
The code is well-structured and readable. It uses clear naming conventions (e.g., CID_MACS, TOKEN_MACS, sign, sign2) and logical organization with static initialization, thread locals, and helper methods separated. Nesting is minimal, with only one try-catch and simple if checks. The intent is clearly documented with a comment explaining why two keys are used. Code length is appropriate—concise without sacrificing clarity. Each line generally performs a single action, improving granularity. Reading flow is natural: constants, static block, thread locals, helper methods, then public methods. Minor deductions: the method names 'sign' and 'sign2' are slightly ambiguous; 'signCid' and 'signToken' would be clearer. Additionally, 'new2' is an awkward name; 'createMac' would be more descriptive. Overall, highly maintainable and easy to follow.
Run 1
Code Structure: Well organized into constants, key initialization, thread-local MAC instances, helpers, and signing entry points. Nesting: Shallow, with only straightforward initialization, exception handling, and a conditional. Clarity of intent: The cryptographic separation comment and descriptive constants help, but names such as new2, sig, sign2, inp3, and out3 obscure purpose; output-length behavior and input-buffer consumption are not documented. Code length: Compact, with shared helpers avoiding substantial duplication; the two thread-local initializers add minor repetition. Action granularity: Statements generally perform one clear action per line. Reading flow: Mostly natural, progressing from setup to operations, though arbitrary numeric suffixes make related methods and variables harder to distinguish.
Run 2
Code Structure: Logically organized into constants, key initialization, thread-local MAC instances, shared helpers, and signing entry points. Nesting: Shallow, with only simple try/catch and conditional blocks; anonymous classes add little complexity. Clarity of intent: The key-separation comment and descriptive constants explain the design, but names such as new2, sig, sign2, inp3, and out3 obscure method roles and parameter meanings. Code length: Compact overall, with modest duplication in the two thread-local initializers that preserves their separation. Action granularity: Each statement performs a single clear action. Reading flow: Mostly natural from setup to implementation to entry points, though arbitrary numeric suffixes force readers to trace calls to distinguish CID signing from token signing.
Run 3
Code Structure: Well organized into constants, key initialization, thread-local MAC instances, shared helpers, and signing methods. Nesting: Shallow, with only straightforward initialization, exception handling, and a conditional. Clarity of intent: The algorithm constant and key-separation comment explain the overall purpose, but names such as new2, sig, sign2, inp3, and out3 obscure method roles and parameter meaning. The input buffer's consumption and output resizing are not explicitly documented. Code length: Compact and mostly appropriate; the two similar thread-local initializers introduce modest duplication. Action granularity: Each statement generally performs one clear action. Reading flow: Initialization precedes helpers and entry points in a logical sequence, though arbitrary numeric suffixes make readers repeatedly trace which signing method uses which key.