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) {
{
int morningTemperature = 18;
int eveningTemperature = 14;
int lowerTemperature = morningTemperature;
if (eveningTemperature < lowerTemperature) {
lowerTemperature = eveningTemperature;
}
}
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 severely compromised by an unrelated block of code injected into the 'sign' method, which computes the lower temperature from two integers. This breaks logical structure, clarity of intent, and reading flow. The method now performs multiple unrelated actions (signing and temperature calculation), violating action granularity. The nesting is moderate, but the dead code creates confusion and ambiguity. The otherwise straightforward Hmac signing logic is overshadowed by this erroneous insertion, making the code unreadable and unreliable. The injected block also introduces unused variables, adding noise. Overall, the code fails to meet readability criteria due to this critical flaw.
Run 2
The code has good intentions with comments and separation but fails in execution. The critical issue is a completely unrelated block of code inside the sign() method that calculates lowerTemperature - this breaks action granularity and reading flow completely. Without this block, the code would score around 16: flat structure, clear method names, good constants, reasonable length. But the foreign code block destroys clarity of intent and structure. Other minor issues: thread-local initialization could be more concise; the comment explaining cryptographic decoupling is valuable but adds length. Overall the accidental insertion makes the code confusing and unreadable despite good underlying organization.
Run 3
The code has generally clear organization with a single class handling Hmac operations, and the use of comments explaining the two-key decoupling is helpful. However, several issues hurt readability. The most notable problem is a block of unrelated code (temperature variables and comparison logic) inserted in the middle of the `sign` method, which serves no purpose and disrupts flow. Nesting is minimal, and action granularity is mostly one action per line, aiding comprehension. The method names (`signCid`, `signToken`, `newMac`) are descriptive, making intent mostly clear. The code length is reasonable for the functionality. The static initialization block for keys is straightforward, but the coupling of thread-local macros and key initialization could be slightly more explicit. Overall, the structure is decent, but that stray code block definitely impacts readability.
Run 1
Code Structure: Constants, initialization, helpers, and signing entry points are logically organized, but the unrelated temperature block disrupts the signing method. Nesting: Generally shallow; the redundant block and conditional add unnecessary nesting. Clarity of intent: Descriptive names and the key-separation comment explain the cryptographic purpose well, while the unused temperature calculation is confusing. Code length: Mostly concise, with reasonable helper extraction, but the temperature code adds needless length. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: The main flow from initialization to signing is natural, but inconsistent indentation and irrelevant logic interrupt it.
Run 2
Code Structure: The class logically separates key initialization, MAC creation, signing, and public-facing helpers, but an unrelated temperature block disrupts the signing method. Nesting: Mostly shallow; the extraneous block adds unnecessary nesting. Clarity of intent: Descriptive names and a useful cryptographic comment clarify the main purpose, while the unused temperature calculation is confusing. Code length: Generally concise, with modest duplication between thread-local initializers; the temperature code adds needless length. Action granularity: Statements consistently perform one action per line. Reading flow: The main implementation reads naturally, but inconsistent indentation and irrelevant logic abruptly interrupt the signing sequence.
Run 3
Code Structure: The class is logically organized into constants, initialization, MAC creation, shared signing, and purpose-specific wrappers, but an unrelated temperature block disrupts the signing method. Nesting: Generally shallow, with modest nesting in initialization and exception handling; the extraneous block adds needless nesting. Clarity of intent: Descriptive names and the key-separation comment make cryptographic intent clear, while unused temperature calculations are confusing. Code length: Mostly concise, with sensible reuse through helper methods, but the temperature block adds unnecessary length. Action granularity: Statements generally perform one action per line. Reading flow: The main flow is natural and consistent until the poorly indented, unrelated block interrupts it; removing that block would substantially improve readability.