5 Inputs and outputs

35.2313GPPDocument 1: Algorithm specificationRelease 17Specification of the TUAK algorithm set: A second example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*TS

5.1 Tuak inputs and outputs

The inputs to Tuak are given in tables 1 and 2, the outputs in tables 3 to 9 below.

There are a few differences from the inputs and outputs to MILENAGE [2].

We allow tThe key K may be 128 bits or 256 bits. MAC-A and MAC-S may be 64, 128 or 256 bits. RES may be 32, 64, 128 or 256 bits. CK and IK may be 128 or 256 bits. Existing 3GPP specifications (see [1] and [12]) do not support all these possibilities, but they are included in Tuak for future flexibility in case future releases of these specifications may want to support them.

NOTE 1: The 3G security architecture specification [1] calls the output of the f1 function ‘MAC’ while the present document and [2] call it ‘MAC-A’.

Any sizes for the parameters K, MAC-A, MAC-S, RES, CK and IK mentioned in the present document shall not be supported nor used in entities defined in 3GPP specifications until these specifications explicitly allow their use.

In any particular implementation, the parameters shall have a fixed length, chosen in advance. For example an operator may fix K at length 256 bits, RES at length 64 bits, CK and IK at length 128 bits. As the lengths do not vary with input, they are not specified as formal input parameters.

Table 1: Inputs to f1 and f1*

Parameter	Size (bits)	Comment
K	128 or 256	Subscriber key K[0]…K[127] or K[0]…K[255]
RAND	128	Random challenge RAND[0]…RAND[127]
SQN	48	Sequence number SQN[0]…SQN[47] (for f1* this input is more precisely called SQNMS)
AMF	16	Authentication management field AMF[0]…AMF[15]

Table 2: Inputs to f2, f3, f4, f5 and f5*

Parameter	Size (bits)	Comment
K	128 or 256	Subscriber key K[0]…K[127] or K[0]…K[255]
RAND	128	Random challenge RAND[0]…RAND[127]

Table 3: f1 output

Parameter	Size (bits)	Comment
MAC-A	64, 128 or 256	Network authentication code MAC-A[0]…MAC-A[63] or MAC-A[0]…MAC-A[127] or MAC-A[0]…MAC-A[255]

Table 4: f1* output

Parameter	Size (bits)	Comment
MAC-S	64, 128 or 256	Resynch authentication code MAC-S[0]…MAC-S[63] or MAC-S[0]…MAC-S[127] or MAC-S[0]…MAC-S[255]

Table 5: f2 output

Parameter	Size (bits)	Comment
RES	32, 64, 128 or 256	Response RES[0]…RES[31] or RES[0]…RES[63] or RES[0]…RES[127] or RES[0]…RES[255]

Table 6: f3 output

Parameter	Size (bits)	Comment
CK	128 or 256	Confidentiality key CK[0]…CK[127] or CK[0]…CK[255]

Table 7: f4 output

Parameter	Size (bits)	Comment
IK	128 or 256	Integrity key IK[0]…IK[127] or IK[0]…IK[255]

Table 8: f5 output

Parameter	Size (bits)	Comment
AK	48	Anonymity key AK[0]…AK[47]

Table 9: f5* output

Parameter	Size (bits)	Comment
AK	48	Resynch anonymity key AK[0]…AK[47]

NOTE 2: Both f5 and f5* outputs are called AK according to [1]. In practice only one of them at a time will be calculated in any given call to the authentication and key agreement algorithms.

5.2 Keccak and its inputs and outputs

This clause refers to the Keccak reference specification [3]. Use is made of the permutation Keccak-f[1600], which is abbreviated to Π, and defined formally in Annex C.

We use Strings IN[0] .. IN[1599] and OUT[0] .. OUT[1599] are used to represent the input and output of Π. As in [3], these are treated as simple bit strings. However, to support efficient implementations of Keccak (see [4]), inputs are mapped to IN and outputs are extracted from OUT in such a way that bits of input and output should not need to be reversed within bytes for such implementations.

The Keccak specification includes the concept of a security parameter which the designers call "capacity". Based on the designers’ recommendations, a formal capacity of 512 bits is used: all input strings to the Keccak permutation shall be padded to 1088 bits, and then have 512 zero bits appended. The padding used to extend the input string to 1088 bits is the "1 0* 1" padding defined in [3], immediately preceded by "1 1 1 1" for consistency with Sakura coding and domain separation (see e.g. " SAKURA: a flexible coding for tree hashing" [5], start of section 6 for the Sakura coding, and Table 4 for the domain separation coding). Note that our input strings before padding are always shorter than 832 bits, with the remaining bits of IN always the same in all modes, and output is only ever extracted from the first 832 bits of OUT – so in practice the effective capacity of the construction is at least 1600 ‑ 832 = 768 bits.

5.3 Other inputs and substrings

MILENAGE uses a 128-bit value OP, and derives a 128-bit value OP_C. OP is an Operator Variant Algorithm Configuration Field.

For Tuak a 256-bit Operator Variant Algorithm Configuration Field is specified, TOP; and a derived 256-bit value TOP_C.

The following internal variables are defined in the algorithm definition:

– A 56-bit string ALGONAME[0] .. ALGONAME[55], with an arbitrary fixed value. This is specified as the ASCII representation of the string "TUAK1.0": to be explicit, ALGONAME[0] .. ALGONAME[55] = 0,1,0,1,0,1,0,0, 0,1,0,1,0,1,0,1, 0,1,0,0,0,0,0,1, 0,1,0,0,1,0,1,1, 0,0,1,1,0,0,0,1, 0,0,1,0,1,1,1,0, 0,0,1,1,0,0,0,0

– An 8-bit string INSTANCE[0] .. INSTANCE[7] which will be given different values for different algorithms within the set.

The internal variable INSTANCE is coded using the following schema (sections 6 gives the exact details) :

INSTANCE[0] .. INSTANCE[1] indicate which function is being implemented

INSTANCE[2]…INSTANCE[4] indicate the length of the MAC-A/MAC-S or RES output,

or they are all set to zero when deriving TOP_C

INSTANCE[5] .. INSTANCE[7] indicate whether the CK/IK/K lengths are 256 bit.