[Cfrg] 5G Encryption and the SNOW-V stream cipher

[John Mattsson <[e-mail]>]

 Hi,

I presented this in SAAG at IETF 104 as CFRGs agenda was completely full. In the end SAAG may have been a better place for a short high level presentation. Thanks for all the good feedback and suggestions during and after the presentation! Sending this email for people that did not attend SAAG.

The background is that 3GPP SA3 has given ETSI SAGE the task to analyse and suggest suitable radio encryption algorithms for later 5G releases (the first releases reuse the 4G/LTE algorithms). The 3GPP radio algorithms are used from the UE to the network:

  - In 2G, the encryption is terminated in the base station.
  - In 3G, it is was decided to terminated encryption deep in the core network (for security reasons).
  - In 4G, it was decided to once again terminated the encryption in the base station (for performance reasons).
  - In 5G, the encryption is formally terminated in the base station, but due to Network Functions Virtualization (NFV) it will in practice be terminated deep in the core network.

[1] gives an overview of the current 3GPP/GSMA Cryptographic Algorithms that all of you all rely on every single day. 5G puts a lot of requirements on the encryption algorithms.

- First, ITM-2020 requires technologies to support at least 20 Gbps downlink to be called 5G. While this will likely not be supported in the first devices, it will very likely be surpassed by later 5G specifications (at least that is what happened with 4G). Optimally the algorithms should work also for future generations of cellular networks.

- Secondly, Network Functions Virtualization (NFV) means that the encryption will be terminated in data centers with various amount of specialized hardware. The current 3GPP algorithms like AES-CTR + AES-CMAC and SNOW 3G does not meet the performance requirements.

Another reason for 3GPP to standardize new algorithms are requirements on 256-bit algorithms from governments wanting to use 5G. A third reason is future proofing, but 3GPP recently concluded that there is no imminent need to replace 128-bit symmetric cryptography. A current working assumption is that ETSI SAGE will recommend algorithms based on AES, SNOW, and ZUC.

Thanks Yoav Nir for pointing out that the performance numbers from 2017 was already significantly outdated. Amazing how fast encryption is on modern CPUs and that Both GCM and OCB really offers integrity protection for free. The numbers for authenticated encryption are the relevant ones in practice. Numbers below from OpenSSL 1.1.1b on and i7-6700K.

                        1024 bytes          16384 bytes 
aes-256-ctr             32.23 Gbps          36.59 Gbps
aes-256-gcm             28.48 Gbps          36.01 Gbps
aes-256-ocb             31.02 Gbps          36.24 Gbps
chacha20                26.17 Gbps          27.72 Gbps
chacha20-poly1305       17.61 Gbps          19.29 Gbps

AES-256-GCM will very likely be a main candidate as its performance even on a single core is well above the current requirements. Another candidate is an update [2] to the SNOW family of algorithms (SNOW 3G is used in 2G, 3G, 4G, and 5G). When the SNOW team tried to see how fast SNOW 3G could be on modern CPU they realized that a slightly updated version designed for modern CPUs could be extremely fast. The current C++ code of SNOW-V significantly outperforms even optimized assembly implementations of AES-CTR and AES-GCM on modern x64 processors. An optimized assembly implementation of SNOW-V-GCM would likely be even faster, but it is hard to say how much. 

SNOW-V                  64.01 Gbps          C++, Alexander Maximov
SNOW-V-GCM              42.40 Gbps          C++, Alexander Maximov
AES-256-CTR             35.75 Gbps          C++, Alexander Maximov
AES-256-GCM             25.50 Gbps          C++, Alexander Maximov
 
AES-256-CTR             34.78 Gbps          Assembly, OpenSSL 1.1.1
AES-256-GCM             34.58 Gbps          Assembly, OpenSSL 1.1.1

SNOW-V is also extremely fast in hardware with quite small and efficient implementations. 3GPP has traditionally standardized and deployed more than one algorithm to be able to immediately switch in case any serious weaknesses are found.

Any suggestion or comments on anything of the above are very welcome! I assume the are many people trying to get fast enough encryption in both software and hardware.

(As Hannes Tschofenig pointed out, 7 mm in the presentation should be 7 nm. A 7 mm process  would lead to very large, slow, and power hungry chipsets ;)

Cheers,
John

[1] https://datatracker.ietf.org/meeting/104/materials/slides-104-saag-snow-v-stream-cipher-00
[2] https://eprint.iacr.org/2018/1143.pdf
[3] https://www.eit.lth.se/fileadmin/eit/home/hs.tjo/presentation.pdf