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 compression, int finalization, byte[] see) {
if (see.length != SEED_LENGTH) {
throw new IllegalArgumentException("seed must be of length " + SEED_LENGTH);
}
this.compressionRounds = ObjectUtil.checkPositive(compression, "compressionRounds");
this.finalizationRounds = ObjectUtil.checkPositive(finalization, "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 key = ByteBuffer.wrap(see).order(ByteOrder.LITTLE_ENDIAN);
final long k = key.getLong();
final long k2 = key.getLong();
initialStateV0 = INITIAL_STATE_V0 ^ k;
initialStateV1 = INITIAL_STATE_V1 ^ k2;
initialStateV2 = INITIAL_STATE_V2 ^ k;
initialStateV3 = INITIAL_STATE_V3 ^ k2;
}
long mac(ByteBuffer inp) {
v0 = initialStateV0;
v1 = initialStateV1;
v2 = initialStateV2;
v3 = initialStateV3;
int rem = inp.remaining();
int pos = inp.position();
int len = rem - (rem % Long.BYTES);
boolean needs = inp.order() == ByteOrder.BIG_ENDIAN;
for (int off = pos; off < len; off += Long.BYTES) {
long m = inp.getLong(off);
if (needs) {
// We use little-endian as in the paper.
m = Long.reverseBytes(m);
}
v3 ^= m;
for (int i = 0; i < compressionRounds; i++) {
sip();
}
v0 ^= m;
}
// Get last bits.
final int lef = rem & (Long.BYTES - 1);
long b = (long) rem << 56;
assert lef < Long.BYTES;
switch (lef) {
case 7:
b |= (long) inp.get(pos + len + 6) << 48;
case 6:
b |= (long) inp.get(pos + len + 5) << 40;
case 5:
b |= (long) inp.get(pos + len + 4) << 32;
case 4:
b |= (long) inp.get(pos + len + 3) << 24;
case 3:
b |= (long) inp.get(pos + len + 2) << 16;
case 2:
b |= (long) inp.get(pos + len + 1) << 8;
case 1:
b |= inp.get(pos + len);
break;
case 0:
break;
default:
throw new IllegalStateException("Unexpected value: " + lef);
}
v3 ^= b;
for (int i = 0; i < compressionRounds; i++) {
sip();
}
v0 ^= b;
v2 ^= 0xFF;
for (int i = 0; i < finalizationRounds; i++) {
sip();
}
return v0 ^ v1 ^ v2 ^ v3;
}
private void sip() {
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 well-structured with clear separation of initialization, processing, and finalization. Nesting is shallow, with only one level inside the main loop. Intent is mostly clear: it implements SipHash with configurable rounds and little-endian handling. Field names are descriptive, and constants include comments. However, the 'mac' method mixes multiple responsibilities (state reset, block processing, tail handling, finalization), and the tail-switch fall-through pattern, while compact, can reduce readability. Variable names like 'k', 'k2', 'b', 'm', and 'needs' are terse. The byte-ordering check and the use of magic numbers (0xFF, shifts) add minor cognitive load. The finalization block could benefit from a comment. Overall, readable for experienced developers familiar with cryptographic hashing, but not immediately accessible to newcomers.
Run 2
The code is moderately readable. It has a clear structure with logical organization into constants, fields, constructor, and methods. Nesting is low and action granularity is mostly one action per line. However, clarity of intent is weak in the `mac` method, especially the switch fall-through for tail bytes, which is difficult to follow. Variable names like `b`, `lef`, and `k2` are cryptic. The reading flow is natural but interrupted by magic numbers and endianness handling. The code is concise, but comments are sparse for the complex parts.
Run 3
The code is generally well-structured and readable. The class has a clear single purpose, fields are logically grouped, and constants are well-named. The constructor validates inputs and initializes state cleanly. The `mac` method shows good decomposition by extracting the compression-round loop into a private `sip()` helper, which keeps each line focused on one action. However, readability is reduced by the large switch statement for tail-byte packing, which uses fall-through cases and byte-level bit manipulation that requires close study. The 'needs' variable and endianness handling, while commented, could be clearer. Overall nesting is shallow and flow is natural, but the tail-processing block prevents a higher score.
Run 1
Code Structure: Constants, initialization, MAC processing, and the SipHash round are logically separated, though mac combines several processing stages. Nesting: Mostly shallow, with only a nested compression loop and an endian conditional. Clarity of intent: Specification references, named constants, and round-count fields help, but abbreviated names such as see, inp, lef, and needs obscure meaning. The switch relies on undocumented fall-through, and length-versus-position arithmetic requires careful interpretation. Code length: Reasonably concise for a cryptographic implementation; repeated operations largely reflect the algorithm rather than unnecessary verbosity. Action granularity: Each statement generally performs one operation, making state updates easy to follow individually. Reading flow: Initialization, block processing, tail packing, and finalization follow a natural sequence, but sparse stage comments, implicit fall-through, and low-level bit manipulation interrupt readability.
Run 2
Code Structure: Constants, initialization, hashing, and round operations are logically separated, though mac combines several processing phases. Nesting: Mostly shallow; nested compression loops and a conditional remain manageable. Clarity of intent: The algorithm reference, descriptive state constants, and endian comments help, but abbreviated names such as see, inp, lef, and needs obscure meaning. Cryptographic rotations and switch fall-through require specialist knowledge, and the fall-through lacks explicit documentation. Code length: Reasonably concise for the algorithm, although mac is relatively long and repeats compression-loop logic. Action granularity: Statements generally perform one operation per line, making state changes easy to follow. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence with useful whitespace. However, the distinction between absolute positions and relative lengths is unclear, increasing the effort needed to understand buffer indexing.
Run 3
Code Structure: Constants, initialization, hashing, and round operations are logically separated, although mac combines several processing phases. Nesting: Mostly shallow; nested compression loops and an endian conditional remain manageable. Clarity of intent: The SipHash reference, named constants, and comments help, but abbreviated names such as see, inp, needs, and lef obscure meaning. The switch's intentional fall-through lacks explanation, and cryptographic operations require algorithm knowledge. Code length: Reasonably concise for the algorithm, though mac is lengthy and could benefit from clearer phase boundaries. Action granularity: Statements generally perform one action per line, making state updates easy to follow. Reading flow: Initialization, block processing, remainder handling, and finalization follow a natural sequence. However, len represents a byte count while off represents an absolute position, making the loop boundary confusing. Minor formatting inconsistencies and vague comments also reduce polish.