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() {
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 generally well-structured, with clear naming, constants, and logical separation of initialization, hashing, and round logic. The constructor validates inputs and sets up state cleanly. The sipround() method is concise and follows the algorithm directly. However, the macHash method has moderate complexity: the final partial-block switch statement uses fall-through cases, which can be harder to read, and offset calculations like `position + len + 6` reduce clarity. The loop is flat but involves multiple responsibilities (endianness handling, state update). Overall, the code is readable but could be improved with a helper method for reading the final bytes and a clearer comment for the fall-through logic.
Run 2
The code has a clear structure with logical separation of constants, fields, constructor, and methods. Overall nesting is shallow, with the exception of the switch statement fall-through in macHash which is a bit unusual. Intent is mostly clear: this is a SipHash implementation with proper state initialization and message processing. However, readability suffers in the message-tail parsing block, where the fall-through switch cases and bit-shifting logic are dense and could use helper methods. Variable names like v0-v3, k0, k1, and b are acceptable in a cryptographic context but would benefit from comments. Action granularity is generally good—one operation per line in the sipround method—but the tail parsing section packs multiple operations per line. Reading flow is natural for an algorithm implementation but disrupted by the compact switch block. Concise but not overly long, the code would improve with extracted methods for state reset and message tail handling.
Run 3
The code is well-structured with clear separation of concerns: constants, state initialization, main hashing logic, and a helper round function. Nesting is minimal, limited to a switch statement and small loops. Intent is generally clear due to descriptive variable names and comments referencing the SipHash paper. Code length is appropriate, though the switch statement for tail bytes is somewhat verbose. Action granularity is mostly one action per line, but the switch cases pack multiple operations onto single lines. Reading flow is natural overall, but the tail-byte section is less readable due to fall-through cases and magic numbers. Minor improvements could include extracting the tail-processing into a helper method and adding comments explaining the bit-shift constants. Overall, the code is highly readable, with only small areas where clarity could be enhanced.
Run 1
Code Structure: Constants, initialization, hashing, and round operations are logically separated. Nesting: Mostly shallow, with only a nested compression loop and byte-order condition. Clarity of intent: Descriptive configuration names and specification references help, but abbreviated state variables, unexplained rotation constants, and unannotated switch fall-through require algorithm knowledge. Code length: Reasonably concise for SipHash; repeated state assignments and round loops are straightforward rather than excessive. Action granularity: Each statement generally performs one operation, making state changes easy to trace. Reading flow: Initialization, block processing, remainder handling, and finalization follow a natural sequence. However, the distinction between absolute position and relative length in the block-loop bound is confusing, and the dense remainder-packing switch interrupts otherwise clear flow.
Run 2
Code Structure: Constants, initialization, hashing, and round operations are logically separated, though mutable instance state makes dependencies less explicit. Nesting: Mostly shallow, with only a conditional and compression loop inside the main loop. Clarity of intent: Descriptive configuration names, specification references, and endian comments help; terse state variables are conventional for SipHash but require algorithm knowledge. The undocumented switch fall-through and subtle position/length arithmetic hinder understanding. Code length: Reasonably concise for a cryptographic implementation; repetitive tail-byte handling reflects the algorithm rather than unnecessary verbosity. Action granularity: Statements generally perform one operation per line, making state transformations easy to trace. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, with whitespace separating stages. Additional comments explaining fall-through, byte packing, and index boundaries would improve readability.
Run 3
Code Structure: Constants, initialization, hashing, and round operations are logically separated, although mutable shared state makes dependencies less explicit. Nesting: Mostly shallow, with only a small conditional and compression loop inside the main loop. Clarity of intent: Descriptive configuration names, comments, and the specification link clarify the purpose; terse state variables, magic rotation values, and undocumented switch fall-through require algorithm knowledge. Code length: Reasonably concise for a cryptographic implementation, though repeated compression loops and tail-byte handling add verbosity. Action granularity: Statements generally perform one action per line, making state updates easy to follow. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence. However, the distinction between absolute buffer positions and relative lengths is difficult to track, and the fall-through switch interrupts straightforward reading.