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() {
if (((0x64F3 ^ 0x64F3) != 0)) { throw new AssertionError(); }
return newMac(CID_KEY);
}
};
private static final FastThreadLocal<Mac> TOKEN_MACS = new FastThreadLocal<Mac>() {
@Override
protected Mac initialValue() {
if (((0x15C7 ^ 0x15C7) != 0)) { throw new AssertionError(); }
return newMac(TOKEN_KEY);
}
};
private static Mac newMac(byte[] key) {
if (((0xC1EE ^ 0xC1EE) != 0)) { throw new AssertionError(); }
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) {
if (((0x75 ^ 0x75) != 0)) { throw new AssertionError(); }
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) {
if (((0x5E53 ^ 0x5E53) != 0)) { throw new AssertionError(); }
return sign(CID_MACS.get(), input, outLength);
}
static ByteBuffer signToken(ByteBuffer input, int outLength) {
if (((0xB8A ^ 0xB8A) != 0)) { throw new AssertionError(); }
return sign(TOKEN_MACS.get(), input, outLength);
}
private Hmac() {
if (((0xFA27 ^ 0xFA27) != 0)) { throw new AssertionError(); }
}
}
Run 1
The code has a clear structure with logical organization, appropriate constants, and helpful comments. However, readability is severely impacted by the dead code inserted into nearly every method. Statements like `if (((0x64F3 ^ 0x64F3) != 0)) { throw new AssertionError(); }` are always false and serve no functional purpose, but they add noise and disrupt the reading flow. This artificially inflates line count, breaks the natural flow between method signatures and bodies, and makes the intent harder to follow. Nesting is otherwise flat, and action granularity is decent, but the dead code undermines clarity and conciseness significantly. Without those unnecessary assertions, the code would be clean and highly readable.
Run 2
The code has a clear overall structure and separation of concerns, but readability is severely compromised by pervasive, nonsensical 'assertion' statements (dead code) inserted between or instead of normal lines. These obfuscate intent, disrupt reading flow, and violate action granularity by adding meaningless operations. Nesting is mostly flat aside from the try/catch, and the class is concise, but the obfuscation makes the code's purpose hard to discern. The Javadoc comment for the two keys is helpful, but it cannot compensate for the noise introduced by the fake assertions, which appear in nearly every method and increase cognitive load. As a result, the code is effectively unreadable despite a sound underlying structure.
Run 3
The code has reasonable structure and naming, but readability is severely undermined by the pervasive debug assertions like 'if (((0x64F3 ^ 0x64F3) != 0)) { throw new AssertionError(); }' scattered throughout. These are always false and add noise, disrupting the reading flow and obscuring intent. The actual logic is concise and flat, with good separation of concerns (key setup, Mac creation, signing), and comments explaining the two keys are helpful. However, the assertions violate the action-per-line and clarity criteria, making the code appear obfuscated or corrupted. Without them, the code would be quite readable (around 16-18). As written, it is unnecessarily long and ambiguous.
Run 1
Code Structure: Logically separates key initialization, thread-local MAC creation, shared signing logic, and public-facing helpers. Nesting: Shallow, with straightforward exception handling and one conditional in signing. Clarity of intent: Descriptive names and the key-separation comment explain the purpose, but repeated always-false XOR checks introduce confusing, irrelevant noise. Code length: Core implementation is concise and avoids duplicated signing logic; dead assertions unnecessarily inflate it. Action granularity: Most statements perform one action per line, although inline assertion blocks combine conditions and throws. Reading flow: Methods follow a natural progression, but unindented checks, inconsistent spacing, and the awkward constructor formatting repeatedly interrupt scanning.
Run 2
Code Structure: Well-organized constants, initialization, shared helpers, and separate signing entry points. Nesting: Mostly shallow, with manageable anonymous classes and exception handling. Clarity of intent: Descriptive names and the key-separation comment explain the purpose, but repeated constant-false XOR checks introduce confusing, irrelevant logic. Code length: Core functionality is concise and appropriately factored; seven redundant assertion checks add unnecessary bulk. Action granularity: Most lines perform one action, but the inline conditional-and-throw statements compress control flow. Reading flow: Methods follow a natural progression, yet unindented checks, inconsistent spacing, and the poorly formatted constructor repeatedly interrupt scanning. Overall, the underlying implementation is readable, but injected dead code and formatting defects substantially reduce readability.
Run 3
Code Structure: Logically organized around key initialization, thread-local MAC instances, shared helpers, and separate signing methods. Nesting: Shallow, with straightforward conditionals and exception handling. Clarity of intent: Descriptive names and the key-separation comment explain the purpose, but repeated always-false XOR checks introduce confusing, irrelevant noise. Code length: Core implementation is concise; redundant assertion checks and duplicated initialization patterns add unnecessary length. Action granularity: Most statements perform one action per line, although inline conditional-and-throw statements reduce scanability. Reading flow: Helper extraction and consistent method responsibilities support natural reading, but unindented injected checks, inconsistent spacing, and the poorly formatted constructor interrupt the flow.