Re: AES-256 only or both AES-256 + AES-128

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Sorry for the long silence. I had to switch to another project temporarily.

I would like to continue our previous discussion, but focus on one question per thread. Other questions will get their own threads.

This one is about supporting both 128 and 256 bit key or only the 256-bit key. Here is what was discussed earlier (copied from the earlier thread):

….

[MH] I do not see much value in supporting 128b keys if 256b keys seem to be the new norm. Given both supported, I would default to 256b key anyway, because why not. Unless there is some substantial pro of still doing 128b keys, I am not sure what it buys us, really.

[GK] I don’t have a strong argument for continued support of 128-bit key. I thought that it was possible that instead of generating keys in the OLT itself, operators will use some external security server. And that external infrastructure may or may not support 256-bit keys in various head ends. Maybe this is not the case. Just want to observe two things:

1. The 128 and 256 refers to only the key size. The AES engine itself is always 128 bit wide.

2. The newest ITU-T PON recommendation G.9804 includes encryption methods with both key sizes: AES-128 (mandatory), AES-256 (mandatory), Camellia-128, Camellia-256, and SM4(-128)

Does anyone have any concerns with not supporting AES-128?

[mh0308] I personally think we should minimize the key size count, not add to the complexity of supporting different encryption schemes. I understand what the driver was on the ITU-T side, but I feel we do not have to deal with that honestly. My vote would be for 256b key only.

[SG] From a risk management perspective, AES 128 is considered sufficiently secure by most authorities at the moment. A lot of SDOs are moving to AES 256, but I think that’s just because they can. It’s my understanding that there is delay added by using 256 relative to 128. However, its small and implementation differences in hardware or software probably matter more than the added number of rounds that AES 256 requires (AES 128 is 10; AES 256 is 14). However, for my part, I tend to want to trust the silicon manufacturers here because implementation matters.

[SG] That said, if we think 256 is more secure, supporting 128 provides a down grade attack path. I so no benefit to requiring 128 if 256 is mandatory and the performance penalty is minimal.

However, I do think now that there are arguments for supporting both key sizes:

1) With large number of ONUs, the key memory is becoming an issue. For a given memory size, using the 128-bit keys, the OLT can support twice as many encryption flows as it can with 256-bit keys. The keys are usually stored in on-chip memory, because the OLT needs to be able to switch a key very quickly when one envelope ends and another envelope starts, as any two adjacent envelopes can be destined to (or arrive from) different ONUs that use different keys.

2) 256-bit keys in PON segment are unnecessary if the rest of the network still uses 128 bit keys. It is better to use smaller keys and allow more of them.

Steve, the MKA allows the SAK to be either 128 or 256 bits wide. What specifically determines whether the 128 bit or 256 SAK is used? If the size of CAK determines the size of SAK, then what determines the size of CAK?

Thank you,

Glen