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 = 0x10;
// 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 = 0x0; i < compressionRounds; i++) {
sipround();
}
v0 ^= m;
}
// Get last bits.
final int left = remaining & (Long.BYTES - 0x1);
long b = (long) remaining << 0x38;
assert left < Long.BYTES;
switch (left) {
case 0x7:
b |= (long) input.get(position + len + 0x6) << 0x30;
case 0x6:
b |= (long) input.get(position + len + 0x5) << 0x28;
case 0x5:
b |= (long) input.get(position + len + 0x4) << 0x20;
case 0x4:
b |= (long) input.get(position + len + 0x3) << 0x18;
case 0x3:
b |= (long) input.get(position + len + 0x2) << 0x10;
case 0x2:
b |= (long) input.get(position + len + 0x1) << 0x8;
case 0x1:
b |= input.get(position + len);
break;
case 0x0:
break;
default:
throw new IllegalStateException("Unexpected value: " + left);
}
v3 ^= b;
for (int i = 0x0; i < compressionRounds; i++) {
sipround();
}
v0 ^= b;
v2 ^= 0xFF;
for (int i = 0x0; i < finalizationRounds; i++) {
sipround();
}
return v0 ^ v1 ^ v2 ^ v3;
}
private void sipround() {
v0 += v1;
v2 += v3;
v1 = Long.rotateLeft(v1, 0xd);
v3 = Long.rotateLeft(v3, 0x10);
v1 ^= v0;
v3 ^= v2;
v0 = Long.rotateLeft(v0, 0x20);
v2 += v1;
v0 += v3;
v1 = Long.rotateLeft(v1, 0x11);
v3 = Long.rotateLeft(v3, 0x15);
v1 ^= v2;
v3 ^= v0;
v2 = Long.rotateLeft(v2, 0x20);
}
}
Run 1
The code is well-structured and readable for a cryptographic implementation. It uses clear naming conventions (INITIAL_STATE_V0, compressionRounds), logical organization with constants separated from state variables, and follows a natural flow from initialization to finalization. The constructor validates inputs properly and comments explain the little-endian choice and reference the SipHash paper. The main hash function is reasonably flat, though the switch statement for trailing bytes uses intentional fall-through which may confuse readers unfamiliar with this pattern. Action granularity is good in the sipround method with one operation per line. Minor readability concerns include heavy use of hexadecimal notation (0x38, 0xD, 0x10) which assumes domain knowledge, and the switch fall-through requires careful reading to understand byte accumulation. Overall, it's concise and maintains clear intent throughout.
Run 2
The code is generally organized but suffers from several readability issues. Structure is logical with clear separation of state initialization and hashing, but the SipHash core algorithm is inherently complex. Nesting is mostly acceptable though the switch fall-through pattern is non-obvious. Intent is clear from comments and method names, but magic hexadecimal constants throughout obscure the algorithm's mathematical constants. Code length is appropriate except for the verbose tail-processing switch. Action granularity is good in most methods. Reading flow is decent but hampered by hexadecimal notation for shifts (0x38, 0x30, etc.) that force mental conversion. The switch fall-through for tail bytes is efficient but hard to follow without comments. Overall the code is maintainable for those familiar with cryptographic implementations, but could be improved with named constants, decimal shifts, and more explicit tail-handling logic.
Run 3
The code has a clear overall structure with constants, fields, constructor, and methods logically organized. However, readability suffers in several areas. The macHash method mixes multiple actions (position calculation, endianness check, loop, tail handling) and uses hexadecimal literals extensively, making intent harder to grasp. The switch statement with fall-through cases is compact but non-obvious; comments only partially clarify the bit-shifting logic. Nesting is low, which is good, but the tail-processing block is dense and breaks the 'one action per line' principle. Magic numbers (0x38, 0x30, etc.) without explanatory constants reduce clarity. The class-level structure and constructor are clean, but the core hashing logic requires domain knowledge to parse easily, placing it mid-range on the readability scale.
Run 1
Code Structure: Constants, state, initialization, hashing, and the round operation are logically separated. Nesting: Mostly shallow, with only modest nesting in block processing. Clarity of intent: Descriptive configuration names, endian comments, and the algorithm reference help, but terse variables, hexadecimal counts, mutable state, and undocumented switch fall-through require cryptographic familiarity. Code length: Reasonably concise for the algorithm, although repeated round loops and explicit tail-byte assembly add verbosity. Action granularity: Statements generally perform one action per line, making transformations easy to follow. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence; however, the distinction between absolute offsets and relative lengths is insufficiently explained, and sparse phase comments make some details harder to track.
Run 2
Code Structure: Constants, initialization, hashing, and the round operation are logically separated, though macHash combines several processing stages. Nesting: Mostly shallow, with only modest nesting inside the block-processing loop. Clarity of intent: Descriptive configuration names, comments, and the algorithm reference help; terse state variables are conventional for SipHash but require familiarity. Hexadecimal loop counters and offsets, unexplained mutable state, and undocumented switch fall-through reduce clarity. Code length: Reasonably concise for a low-level cryptographic implementation, with some repetitive state assignments and round loops. Action granularity: Each statement performs a single operation, making state changes easy to trace. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence. However, the relationship between position, len, and the loop boundary is not immediately clear, and tail assembly requires careful reading.
Run 3
Code Structure: Constants, initialization, hashing, and round operations are logically separated, although macHash combines several processing stages. Nesting: Mostly shallow, with manageable nested compression loops and a switch. Clarity of intent: Descriptive configuration names, comments, and the algorithm reference help; terse state variables, hexadecimal loop counters and offsets, and undocumented switch fall-through make details harder to follow. Code length: Reasonably concise for a low-level hashing implementation, though tail assembly is repetitive. Action granularity: Each statement generally performs one operation, making state changes easy to trace. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, with whitespace separating stages. However, mixing absolute positions with relative lengths requires extra scrutiny, and mutable instance state introduces implicit dependencies between methods.