Provision for authenticated encryption?

View previous topic View next topic Go down

Provision for authenticated encryption?

Post  sgteo on Wed Aug 18, 2010 9:53 pm

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?


sgteo

Posts : 8
Join date : 2010-08-13

View user profile

Back to top Go down

Re: Provision for authenticated encryption?

Post  Xiutao Feng on Fri Aug 20, 2010 6:46 pm

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.

2) What is the MAC calculated over? The plaintext or ciphertext?
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.

Xiutao Feng

Posts : 13
Join date : 2010-08-20

View user profile

Back to top Go down

Re: Provision for authenticated encryption?

Post  Steve Babbage on Mon Aug 23, 2010 3:38 am

2) What is the MAC calculated over? The plaintext or ciphertext?
Rather bizarrely, it seems that the answer is "both".

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

View user profile

Back to top Go down

Re: Provision for authenticated encryption?

Post  severns on Thu Aug 26, 2010 1:46 pm

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?

severns

Posts : 2
Join date : 2010-08-20

View user profile

Back to top Go down

Re: Provision for authenticated encryption?

Post  Steve Babbage on Wed Sep 01, 2010 2:38 am

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 ....)

Steve Babbage

Posts : 30
Join date : 2010-08-02

View user profile

Back to top Go down

Maximum message size

Post  sgteo on Wed Oct 06, 2010 10:43 pm

Could I confirm that the maximum size of messages for 1 encryption/decryption session is 65,504 bits?
Thanks.

sgteo

Posts : 8
Join date : 2010-08-13

View user profile

Back to top Go down

Re: Maximum message size

Post  Steve Babbage on Mon Oct 11, 2010 6:45 am

sgteo wrote:Could I confirm that the maximum size of messages for 1 encryption/decryption session is 65,504 bits?
Thanks.
Yes, I have checked with colleagues and I can confirm that the maximum message size is 8188 bytes = 65504 bits.

Steve Babbage

Posts : 30
Join date : 2010-08-02

View user profile

Back to top Go down

Re: Provision for authenticated encryption?

Post  Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum