Provision for authenticated encryption?
4 posters
Page 1 of 1
Provision for authenticated encryption?
I just had a quick read of the specifications and have a couple of questions
1) Is there any way you can provide authenticated encryption (AE)? It appears that the confidentiality and integrity algorithms are separate. That is, you need to reinitialize the internal state before you compute the MAC, which is unlike the AE stream ciphers in eSTREAM.
2) What is the MAC calculated over? The plaintext or ciphertext?
1) Is there any way you can provide authenticated encryption (AE)? It appears that the confidentiality and integrity algorithms are separate. That is, you need to reinitialize the internal state before you compute the MAC, which is unlike the AE stream ciphers in eSTREAM.
2) What is the MAC calculated over? The plaintext or ciphertext?
sgteo- Posts : 8
Join date : 2010-08-13
Re: Provision for authenticated encryption?
1) Is there any way you can provide authenticated encryption (AE)? It appears that the confidentiality and integrity algorithms are separate. That is, you need to reinitialize the internal state before you compute the MAC, which is unlike the AE stream ciphers in eSTREAM.
Yes. Once we tended to design such a algorithm. But since the encryption and authentication are not always used together in the context of 3GPP LTE, for example, only the encryption on user's data in the UP layer is required, hence we finally decide to design two algorithms, similar to 128-EEA1/2 and 128-EIA1/2.
The MAC is calculated over the keystream generated by ZUC under the control of an integrity key IK and an initial vector IV according to bit informaton of plaintexts.2) What is the MAC calculated over? The plaintext or ciphertext?
Xiutao Feng- Posts : 13
Join date : 2010-08-20
Re: Provision for authenticated encryption?
Rather bizarrely, it seems that the answer is "both".2) What is the MAC calculated over? The plaintext or ciphertext?
On one layer of the protocol, between mobile phone and base station, integrity is applied before ciphering for the radio signalling bearer (like TLS). But on another layer, between the mobile phone and a node deeper in the network, ciphering is applied before integrity (like IPsec). Different key sets are used on the two layers, and as Xiutao explained, the keys for encryption and integrity are always distinct (and cryptographically separated).
The fact that the order is different on the two layers seems to be for reasons relating to the design history of LTE. It is true irrespective of the choice of algorithm.
So from the point of view of an attacker you can assume whichever you prefer (but remembering that the encryption and integrity keys are different).
Steve Babbage- Posts : 30
Join date : 2010-08-02
Re: Provision for authenticated encryption?
I have two questions:
1. The protocol layer in which encryption/integrity occurs that you refer to between the mobile phone and base station is PDCP (TS36.323). It's interesting that in PDCP they define the largest SDU size as 8188 byte: "The maximum supported size of a PDCP SDU is 8188 octets." So the max size packet to have ZUC applied is 8188 * 8 = 65,504 bits (ignoring ROHC compression for the moment). It's true that both Kasumi and SNOW3G are defined as a maximum size of 20,000 bits for legacy reasons. But I expected to see ZUC defined for more than 20K bit messages. Why is it still spec'ed at 20K max bit for keystream when the protocol using it specifies the packet data as larger?
2. You refer to a second protocol layer in which ciphering is applied before integrity "But on another layer, between the mobile phone and a node deeper in the network, ciphering is applied before integrity (like IPsec)". Can you tell me what layer that is and what the 3GPP specification number is for that?
1. The protocol layer in which encryption/integrity occurs that you refer to between the mobile phone and base station is PDCP (TS36.323). It's interesting that in PDCP they define the largest SDU size as 8188 byte: "The maximum supported size of a PDCP SDU is 8188 octets." So the max size packet to have ZUC applied is 8188 * 8 = 65,504 bits (ignoring ROHC compression for the moment). It's true that both Kasumi and SNOW3G are defined as a maximum size of 20,000 bits for legacy reasons. But I expected to see ZUC defined for more than 20K bit messages. Why is it still spec'ed at 20K max bit for keystream when the protocol using it specifies the packet data as larger?
2. You refer to a second protocol layer in which ciphering is applied before integrity "But on another layer, between the mobile phone and a node deeper in the network, ciphering is applied before integrity (like IPsec)". Can you tell me what layer that is and what the 3GPP specification number is for that?
severns- Posts : 2
Join date : 2010-08-20
Re: Provision for authenticated encryption?
Response to the posting above from severns:
1. "Why is [ZUC] still spec'ed at 20K max bit for keystream when the protocol using it specifies the packet data as larger?" Well spotted, thank you. This was just down to a communication failure between the 3GPP standards team and the team specifying the algorithm. The algorithm should be specified to cover at least the maximum size needed by the system, and we will make this change to the document. As you would expect, the algorithms have in practice been designed to remain secure with far larger packet sizes than that, so this makes no significant difference to the security analysis.
2. The layer in which ciphering is applied before integrity is the Non-Access Stratum, defined in 3GPP 24.301. ("NAS layer" was tautological - sorry ....)
1. "Why is [ZUC] still spec'ed at 20K max bit for keystream when the protocol using it specifies the packet data as larger?" Well spotted, thank you. This was just down to a communication failure between the 3GPP standards team and the team specifying the algorithm. The algorithm should be specified to cover at least the maximum size needed by the system, and we will make this change to the document. As you would expect, the algorithms have in practice been designed to remain secure with far larger packet sizes than that, so this makes no significant difference to the security analysis.
2. The layer in which ciphering is applied before integrity is the Non-Access Stratum, defined in 3GPP 24.301. ("NAS layer" was tautological - sorry ....)
Steve Babbage- Posts : 30
Join date : 2010-08-02
Maximum message size
Could I confirm that the maximum size of messages for 1 encryption/decryption session is 65,504 bits?
Thanks.
Thanks.
sgteo- Posts : 8
Join date : 2010-08-13
Re: Maximum message size
Yes, I have checked with colleagues and I can confirm that the maximum message size is 8188 bytes = 65504 bits.sgteo wrote:Could I confirm that the maximum size of messages for 1 encryption/decryption session is 65,504 bits?
Thanks.
Steve Babbage- Posts : 30
Join date : 2010-08-02
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum