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 a, int c, byte[] d) {
if (d.length != SEED_LENGTH) {
throw new IllegalArgumentException("seed must be of length " + SEED_LENGTH);
}
this.compressionRounds = ObjectUtil.checkPositive(a, "compressionRounds");
this.finalizationRounds = ObjectUtil.checkPositive(c, "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 e = ByteBuffer.wrap(d).order(ByteOrder.LITTLE_ENDIAN);
final long f = e.getLong();
final long g = e.getLong();
initialStateV0 = INITIAL_STATE_V0 ^ f;
initialStateV1 = INITIAL_STATE_V1 ^ g;
initialStateV2 = INITIAL_STATE_V2 ^ f;
initialStateV3 = INITIAL_STATE_V3 ^ g;
}
long a(ByteBuffer h) {
v0 = initialStateV0;
v1 = initialStateV1;
v2 = initialStateV2;
v3 = initialStateV3;
int j = h.remaining();
int k = h.position();
int l = j - (j % Long.BYTES);
boolean n = h.order() == ByteOrder.BIG_ENDIAN;
for (int o = k; o < l; o += Long.BYTES) {
long m = h.getLong(o);
if (n) {
// We use little-endian as in the paper.
m = Long.reverseBytes(m);
}
v3 ^= m;
for (int i = 0; i < compressionRounds; i++) {
b();
}
v0 ^= m;
}
// Get last bits.
final int p = j & (Long.BYTES - 1);
long b = (long) j << 56;
assert p < Long.BYTES;
switch (p) {
case 7:
b |= (long) h.get(k + l + 6) << 48;
case 6:
b |= (long) h.get(k + l + 5) << 40;
case 5:
b |= (long) h.get(k + l + 4) << 32;
case 4:
b |= (long) h.get(k + l + 3) << 24;
case 3:
b |= (long) h.get(k + l + 2) << 16;
case 2:
b |= (long) h.get(k + l + 1) << 8;
case 1:
b |= h.get(k + l);
break;
case 0:
break;
default:
throw new IllegalStateException("Unexpected value: " + p);
}
v3 ^= b;
for (int i = 0; i < compressionRounds; i++) {
b();
}
v0 ^= b;
v2 ^= 0xFF;
for (int i = 0; i < finalizationRounds; i++) {
b();
}
return v0 ^ v1 ^ v2 ^ v3;
}
private void b() {
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 is structurally coherent with clear separation of constants, state, and methods, but it suffers from poor naming and deeply opaque variable names (v0-v3, a-j, k, l, m, b). The SipHash algorithm itself is inherently complex, but the use of single-letter variables throughout the main hash method makes the logic extremely hard to follow and requires constant mental mapping. The fall-through switch cases for tail byte handling are dangerous and obscure, and the mixing of state mutations with loop logic violates action granularity. While the initialization constructor is reasonably readable, the core hashing method contains overly compressed expressions and unclear indices. The code is allocation-free and follows the paper's structure, but without meaningful variable names or comments on each step, it reads like a direct transcription of pseudocode rather than maintainable production code.
Run 2
This code is nearly unreadable due to single-letter variable names (a, b, c, d, e, f, g, h, j, k, l, m, n, o, p) that completely obscure the intent. The method names `a()` and `b()` convey no meaning. The fall-through switch statement for bit-packing adds complexity and risk. The scoring criteria all fail: code structure is tangled despite a logical algorithm, clarity of intent is extremely low, reading flow is disorganized due to cryptic naming, and action granularity is mixed. While nesting is relatively flat and the length is compact, these positives are overwhelmed by the cryptic naming. The comments referencing 'the paper' do little to clarify the implementation details. Using meaningful variable names (e.g., `inputBuffer`, `chunkCount`, `lastBlock`, `initialState`) would dramatically improve readability.
Run 3
This code is nearly unreadable due to heavy obfuscation with meaningless variable names like a, c, d, b(), h, j, k, l, n, m, o, and p. The method name 'a' gives no indication of its purpose, and 'b' obscures the SipHash compression round. Despite clear structure and flat nesting, the lack of semantic naming destroys clarity of intent and action granularity. The original cryptographic constants are well documented, but the parameter and local naming destroys readability, violating Java conventions. The code mixes precision with poor naming, making it extremely hard to follow.
Run 1
Code Structure: Constants, initialization, hashing, and round operations are logically separated into a compact class. Nesting: Mostly shallow, with only modest nesting in the block-processing loop. Clarity of intent: SipHash documentation, descriptive state constants, and explanatory comments help, but single-letter parameters, locals, and method names obscure their roles. The switch's intentional fall-through is not explicitly documented, and index calculations are difficult to interpret. Code length: Reasonably concise for a low-level hashing implementation; repetitive operations largely reflect the algorithm. Action granularity: Statements consistently perform one operation per line, making state changes easy to inspect individually. Reading flow: Initialization, compression, tail handling, and finalization follow a natural sequence, but cryptic naming and dense bit manipulation force readers to reconstruct meaning. Overall, the organization is solid, while poor naming substantially reduces readability.
Run 2
Code Structure: Constants, initialization, hashing, and the mixing round are logically separated. Nesting: Mostly shallow, with manageable nested loops and conditionals. Clarity of intent: The SipHash reference, descriptive state fields, and comments help, but single-letter parameters, locals, and method names obscure meaning; the local b and method b() are particularly confusing. Code length: Reasonably concise for the algorithm, although the main hashing method is lengthy. Action granularity: Nearly every line performs one action, making state updates easy to follow individually. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, but undocumented switch fall-through, cryptographic constants, and unclear offset names require careful interpretation.
Run 3
Code Structure: Constants, initialization, hashing, and round operations are logically separated into a compact class. Nesting: Mostly shallow, with only modest nesting inside the block-processing loop. Clarity of intent: SipHash documentation and descriptive state fields help, but single-letter parameters, locals, and method names obscure important roles; the variable b and method b() are particularly confusing. Code length: Reasonably concise for this algorithm, with little unnecessary code. Action granularity: Statements generally perform one action per line, making state updates easy to follow individually. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, but cryptographic operations require domain knowledge. Undocumented switch fall-through and terse comments weaken comprehension, while the loop's mixture of absolute positions and relative lengths makes its bounds difficult to interpret confidently.