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 a() {
return b(CID_KEY);
}
};
private static final FastThreadLocal<Mac> TOKEN_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac a() {
return b(TOKEN_KEY);
}
};
private static Mac b(byte[] a) {
try {
SecretKeySpec b = new SecretKeySpec(a, ALGORITHM);
Mac c = Mac.getInstance(ALGORITHM);
c.init(b);
return c;
} catch (NoSuchAlgorithmException | InvalidKeyException d) {
throw new IllegalStateException(d);
}
}
private static ByteBuffer c(Mac e, ByteBuffer f, int g) {
e.reset();
e.update(f);
byte[] h = e.doFinal();
if (h.length != g) {
h = Arrays.copyOf(h, g);
}
return ByteBuffer.wrap(h);
}
static ByteBuffer d(ByteBuffer i, int j) {
return c(CID_MACS.get(), i, j);
}
static ByteBuffer e(ByteBuffer k, int l) {
return c(TOKEN_MACS.get(), k, l);
}
private Hmac() { }
}
Run 1
The code structure is not well-organized due to single-letter method and variable names (a, b, c, d, e, f, g, etc.) that obscure intent. This makes the code ambiguous and hard to follow. The nesting is relatively flat, which is good, and action granularity is mostly one action per line. However, readability suffers significantly from poor naming, making it unnecessarily difficult to understand the purpose of each method and variable. Reading flow is disorganized because readers must mentally map cryptic names to their roles. The code length is concise, but brevity comes at the expense of clarity. Comments on the key decoupling are helpful, but they don't compensate for opaque method names. Overall, the code is functionally compact but poorly structured for human comprehension.
Run 2
The code is well-structured with clear sections: constants, key initialization, thread-local Mac instances, and utility methods. The flat hierarchy and single-level nesting in control flow enhance readability. While method names like a(), b(), c(), d(), and e() are opaque, the explanatory comments about cryptographic decoupling and the consistent pattern of one operation per line improve clarity. The use of try-catch for multiple exceptions is concise, and the helper method encapsulation avoids duplication. The only drawbacks are the abbreviated method/parameter names, which slightly reduce intent clarity, and the lack of Javadoc for public methods. Overall, the code demonstrates strong organization, minimal nesting, and good reading flow, making it highly readable despite minor naming weaknesses.
Run 3
The code has severe readability issues. Method and variable names are cryptic single letters (a, b, c, d, e, f, g, h, i, j, k, l), making the logic difficult to follow. The overridden FastThreadLocal method 'a()' obscures intent, and the helper method 'b()' uses confusingly named parameters. Critical cryptographic operations lack descriptive naming despite a helpful comment. The try-catch structure is reasonable, but the overall flow is unnatural, requiring the reader to repeatedly jump between terse methods. The class is concise but at the expense of clarity. While import statements and structure are organized, the naming and parameter choices make the code feel obfuscated and violate clear-intent principles.
Run 1
Code Structure: Logically separates key initialization, thread-local MAC instances, MAC creation, signing, and public-facing wrappers. Nesting: Shallow, with only simple try/catch and conditional blocks. Clarity of intent: Descriptive constants and the cryptographic-decoupling comment help, but single-letter method and variable names obscure operations, parameters, and the distinction between signing entry points. Code length: Compact and mostly justified; the two thread-local initializers introduce minor repetition. Action granularity: Generally one action per line, making individual steps easy to follow. Reading flow: Proceeds naturally from configuration to helpers and wrappers, but readers must repeatedly trace ambiguous names to understand behavior. Overall, strong organization and low nesting are substantially undermined by poor naming.
Run 2
Code Structure: Well organized into constants, key initialization, thread-local instances, shared helpers, and entry points. Nesting: Shallow, with only a try/catch and a simple conditional. Clarity of intent: Descriptive constants and the cryptographic separation comment help, but single-letter method and parameter names obscure initialization, signing, and output-length handling. Code length: Compact without significant unnecessary code; parallel thread-local declarations introduce modest duplication. Action granularity: Generally one action per line, making individual operations easy to follow. Reading flow: The organization is natural, but readers must repeatedly trace ambiguous names to understand the helpers and distinguish the two entry points. Overall, strong structural readability is substantially weakened by opaque naming.
Run 3
Code Structure: Logically organized into constants, key initialization, thread-local MAC instances, helpers, and entry points. Nesting: Shallow, with only a try/catch and a simple conditional. Clarity of intent: Descriptive constants and the security comment explain key separation, but single-letter method and variable names obscure initialization, signing, inputs, and output lengths. Code length: Compact, with shared helpers avoiding substantial duplication; separate thread-local declarations are reasonable. Action granularity: Each statement generally performs one action, making individual operations easy to follow. Reading flow: The top-to-bottom organization is natural, but readers must repeatedly trace opaque identifiers to understand the helpers and distinguish entry points. Overall, good structural readability is significantly weakened by naming.