Source code
package io.netty.handler.codec.quic;
import io.netty.util.internal.ObjectUtil;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
/**
* <a href="https://www.aumasson.jp/siphash/siphash.pdf">Siphash implementation</a>.
*/
final class SipHash {
static final int SEED_LENGTH = 16;
// Make this class allocation free as soon as its constructed.
private final int compressionRounds;
private final int finalizationRounds;
// As specified in https://www.aumasson.jp/siphash/siphash.pdf
private static final long INITIAL_STATE_V0 = 0x736f6d6570736575L; // "somepseu"
private static final long INITIAL_STATE_V1 = 0x646f72616e646f6dL; // "dorandom"
private static final long INITIAL_STATE_V2 = 0x6c7967656e657261L; // "lygenera"
private static final long INITIAL_STATE_V3 = 0x7465646279746573L; // "tedbytes"
private final long initialStateV0;
private final long initialStateV1;
private final long initialStateV2;
private final long initialStateV3;
private long v0;
private long v1;
private long v2;
private long v3;
SipHash(int compressionRounds, int finalizationRounds, byte[] seed) {
if (seed.length != SEED_LENGTH) {
throw new IllegalArgumentException("seed must be of length " + SEED_LENGTH);
}
this.compressionRounds = ObjectUtil.checkPositive(compressionRounds, "compressionRounds");
this.finalizationRounds = ObjectUtil.checkPositive(finalizationRounds, "finalizationRounds");
// Wrap the seed to extract two longs that will be used to generate the initial state.
// Use little-endian as in the paper.
ByteBuffer keyBuffer = ByteBuffer.wrap(seed).order(ByteOrder.LITTLE_ENDIAN);
final long k0 = keyBuffer.getLong();
final long k1 = keyBuffer.getLong();
initialStateV0 = INITIAL_STATE_V0 ^ k0;
initialStateV1 = INITIAL_STATE_V1 ^ k1;
initialStateV2 = INITIAL_STATE_V2 ^ k0;
initialStateV3 = INITIAL_STATE_V3 ^ k1;
}
long macHash(ByteBuffer input) {
v0 = initialStateV0;
v1 = initialStateV1;
v2 = initialStateV2;
v3 = initialStateV3;
int remaining = input.remaining();
int position = input.position();
int len = remaining - (remaining % Long.BYTES);
boolean needsReverse = input.order() == ByteOrder.BIG_ENDIAN;
for (int offset = position; offset < len; offset += Long.BYTES) {
long m = input.getLong(offset);
if (needsReverse) {
// We use little-endian as in the paper.
m = Long.reverseBytes(m);
}
v3 ^= m;
for (int i = 0; i < compressionRounds; i++) {
sipround();
}
v0 ^= m;
}
// Get last bits.
final int left = remaining & (Long.BYTES - 1);
long b = (long) remaining << 56;
assert left < Long.BYTES;
switch (left) {
case 7:
b |= (long) input.get(position + len + 6) << 48;
case 6:
b |= (long) input.get(position + len + 5) << 40;
case 5:
b |= (long) input.get(position + len + 4) << 32;
case 4:
b |= (long) input.get(position + len + 3) << 24;
case 3:
b |= (long) input.get(position + len + 2) << 16;
case 2:
b |= (long) input.get(position + len + 1) << 8;
case 1:
b |= input.get(position + len);
break;
case 0:
break;
default:
throw new IllegalStateException("Unexpected value: " + left);
}
v3 ^= b;
for (int i = 0; i < compressionRounds; i++) {
sipround();
}
v0 ^= b;
v2 ^= 0xFF;
for (int i = 0; i < finalizationRounds; i++) {
sipround();
}
return v0 ^ v1 ^ v2 ^ v3;
}
private void sipround() {
{int lI0O_18f2b296=0xB243;lI0O_18f2b296=(lI0O_18f2b296<<1)^(lI0O_18f2b296>>>1);lI0O_18f2b296&=0;}
v0 += v1;
v2 += v3;
v1 = Long.rotateLeft(v1, 13);
v3 = Long.rotateLeft(v3, 16);
v1 ^= v0;
v3 ^= v2;
v0 = Long.rotateLeft(v0, 32);
v2 += v1;
v0 += v3;
v1 = Long.rotateLeft(v1, 17);
v3 = Long.rotateLeft(v3, 21);
v1 ^= v2;
v3 ^= v0;
v2 = Long.rotateLeft(v2, 32);
}
}
Run 1
The code has a clear structure with constants and state fields separated, but readability is severely damaged by a suspicious injected line in sipround() containing obfuscated variable names and meaningless operations. The fall-through switch cases for handling remaining bytes are idiomatic but may confuse readers unfamiliar with the pattern. The algorithm logic is hard to follow without comments explaining the SipHash rounds. Nesting is shallow and action granularity is generally good, but the obfuscated line breaks reading flow and raises code-quality concerns. The class is allocation-free and concise, but the unexplained magic constants and bitwise operations reduce clarity of intent.
Run 2
The code has some good structural elements—constants are named, state initialization is separated from hashing, and the overall SipHash algorithm is recognizable. However, there are several serious readability issues. The `macHash` method is long and mixes multiple responsibilities: state reset, bulk processing, tail handling, and finalization all in one method. The fall-through switch for tail bytes is compact but non-obvious and error-prone for readers unfamiliar with the algorithm. The biggest problem is the dead code injected in `sipround()`: `{int lI0O_18f2b296=0xB243;lI0O_18f2b296=(lI0O_18f2b296<<1)^(lI0O_18f2b296>>>1);lI0O_18f2b296&=0;}`. This block has no effect, uses obfuscated naming, and completely disrupts reading flow. The method also performs multiple bitwise operations on each line, reducing per-line clarity. Magic numbers like `0xFF` and bit-shift offsets are unexplained. Overall, while the code is not totally unstructured, extraneous code, monolithic method bodies, and unclear tail processing significantly harm readability.
Run 3
The code has some readable aspects (clear field names, comments explaining constants, logical method separation) but is severely impacted by a suspicious obfuscated block inside sipround(). The structure is mostly logical, but macHash() is long with multiple responsibilities (initialization, processing, padding, and finalization), and the switch statement with deliberate fallthrough hurts clarity. There's a moderate nesting depth from loops and switch cases. Action granularity is mostly reasonable, but the obfuscated line violates clarity of intent and is likely a red flag — it looks like intentionally unreadable code. The padding logic is hard to follow without documentation. The method does have a natural flow when read linearly, but the combination of bit manipulation, endianness handling, and the obfuscated line makes it hard to trust the code's correctness from reading alone. It's not completely unreadable, but the obfuscation and long method drag the score down.
Run 1
Code Structure: Constants, initialization, hashing, and round operations are logically separated into a cohesive class. Nesting: Mostly shallow, with modest nesting for compression loops and byte-order handling. Clarity of intent: Descriptive configuration names, specification references, and comments explain the algorithm, but terse state variables and an unexplained switch fall-through require specialized knowledge. The obfuscated, apparently useless block in sipround substantially undermines clarity. Code length: Generally appropriate for the algorithm, although the extraneous block adds unnecessary code. Action granularity: Most statements perform one action per line, except the obfuscated block, which packs several operations together. Reading flow: Initialization, block processing, remainder handling, and finalization follow a natural sequence. However, the abrupt obfuscated insertion interrupts that flow, and the relationship between position, len, and the loop boundary is difficult to interpret.
Run 2
Code Structure: Constructor, hashing method, and round helper provide logical separation, but the meaningless block in sipround disrupts organization. Nesting: Mostly shallow, with manageable nested loops and a switch. Clarity of intent: Descriptive constants, round counts, and specification references explain the algorithm; terse state names are conventional for SipHash. However, the obfuscated variable and unexplained switch fall-through obscure intent. Code length: Generally proportionate to the algorithm, except for the unnecessary injected block. Action granularity: Most lines perform one operation, but the injected block compresses several unrelated operations onto one line. Reading flow: Initialization, compression, tail processing, and finalization follow a natural sequence. Inconsistent formatting and the abrupt obfuscated block interrupt that flow, while offset-versus-length arithmetic requires careful interpretation.
Run 3
Code Structure: Constants, initialization, hashing, and round operations are logically separated, but an unrelated obfuscated block disrupts sipround(). Nesting: Generally shallow, with manageable nested loops and conditionals. Clarity of intent: Descriptive method names, named constants, and specification comments establish the purpose; cryptographic state names and unexplained switch fall-through require specialized knowledge. The meaningless lI0O_18f2b296 variable significantly reduces clarity. Code length: Mostly appropriate for the algorithm, though the injected block adds unnecessary code. Action granularity: Most statements perform one action per line, but the obfuscated block packs several operations onto a single line. Reading flow: Initialization, compression, tail processing, and finalization follow a natural sequence, interrupted by the poorly formatted block and insufficient explanation of tail-byte assembly.