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() {
{int lI0O_05b17a3d=0x9771,lI0O_dbdaa900=~lI0O_05b17a3d;lI0O_05b17a3d=(lI0O_05b17a3d&lI0O_dbdaa900)|(lI0O_05b17a3d^lI0O_05b17a3d);lI0O_dbdaa900^=lI0O_dbdaa900;}
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 has good intentions with clear constants, documentation, and a clean structure at the top level (separate methods, static initializers). However, it contains a suspicious line inside the anonymous FastThreadLocal subclass: a meaningless variable manipulation (lI0O_05b17a3d, lI0O_dbdaa900) that does nothing and obscures intent. This suggests either injected code or obfuscation, drastically harming readability. Additionally, the anonymous inner classes add moderate nesting. The `sign` method is clear but the `if (signBytes.length != outLength)` check is redundant given HmacSHA256 always outputs 32 bytes (unless custom out lengths are passed). Overall, clarity is decent for the crypto utility but undermined by the dead code and slight unnecessary complexity.
Run 2
The code has severe readability problems. The most critical issue is the injected obfuscated line inside the CID_MACS initialValue() method (line with lI0O_05b17a3d variables), which is meaningless noise and breaks trust in the entire file. Beyond that, the overall structure is reasonable: constants, static initialization, thread-local Macs, helper methods, and public API are logically organized. Nesting is minimal and the intent of CID vs token signing is clearly documented. However, the obfuscated line destroys clarity, introduces multiple actions on one line, and interrupts natural reading flow. Code length is appropriate for the task, and action granularity is mostly one action per line except for the obfuscated line and the combined catch clause. Without the injected code, this would be quite readable, but as presented it fails on clarity, structure, and maintainability.
Run 3
The code has a clear structure with logical separation of constants, static initialization, and methods, but it is severely undermined by a block of obfuscated code in the CID_MACS initializer. The line `{int lI0O_05b17a3d=0x9771,lI0O_dbdaa900=~lI0O_05b17a3d;...}` is completely unreadable, serves no apparent purpose, and destroys the clarity of intent. Nesting is generally low, and action granularity is mostly one action per line outside the obfuscated block. The comments explaining the two keys are helpful, and method names like signCid and signToken convey purpose well. However, the presence of dead/obfuscated code makes the overall reading flow jarring and ambiguous, dragging the score down significantly despite otherwise clean structure.
Run 1
Code Structure: Well-organized constants, initialization, factory, shared signing helper, and public-facing operations. Nesting: Generally shallow; anonymous classes and exception handling remain manageable. Clarity of intent: Descriptive names and the key-separation comment explain the cryptographic purpose, but the opaque variable names and meaningless bitwise block obscure one initializer. Code length: Mostly concise, with appropriate helper reuse; the injected block is unnecessary. Action granularity: Most lines perform one action, but the injected block packs several declarations and assignments onto a single line. Reading flow: Methods follow a natural setup-to-operation progression, interrupted sharply by the unindented obfuscated block.
Run 2
Code Structure: Well-organized constants, key initialization, thread-local MAC instances, and focused helper methods; an unrelated obfuscated block disrupts the design. Nesting: Generally shallow, with straightforward exception handling and a single conditional, although anonymous classes add some depth. Clarity of intent: Descriptive names and the key-separation comment explain the cryptographic purpose, but meaningless variable names and redundant bitwise operations obscure one initializer. Code length: Mostly concise, with shared helpers avoiding duplication; the obfuscated block adds unnecessary code. Action granularity: Most statements perform one action per line, but the injected block compresses declarations and several operations onto one line. Reading flow: The overall progression from configuration to initialization and signing is natural, interrupted sharply by the unindented, irrelevant block.
Run 3
Code Structure: Logical separation of key initialization, thread-local MAC instances, MAC creation, and signing helpers. Nesting: Mostly shallow, with straightforward try/catch and conditional blocks; anonymous classes add modest nesting. Clarity of intent: Descriptive names and a useful security comment explain the purpose, but the opaque, seemingly purposeless bitwise block in CID_MACS.initialValue sharply reduces clarity. Code length: Generally concise with shared helpers avoiding duplication, except for the unnecessary obfuscated block. Action granularity: Most statements perform one action per line, but that block compresses multiple declarations and operations into a single line. Reading flow: Initialization followed by helpers and public-facing signing methods is natural; inconsistent formatting and the unexplained injected block interrupt an otherwise clean flow.