InternetDraft  Encryption algorithm RoccaS  November 2022 
Nakano, et al.  Expires 9 May 2023  [Page] 
 Workgroup:
 Network Working Group
 InternetDraft:
 draftnakanoroccas02
 Published:
 Intended Status:
 Informational
 Expires:
Encryption algorithm RoccaS
Abstract
This document defines RoccaS encryption scheme, which is an Authenticated Encryption with Associated Data (AEAD), using a 256bit key and can be efficiently implemented utilizing the AES New Instruction set (AESNI).¶
Status of This Memo
This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current InternetDrafts is at https://datatracker.ietf.org/drafts/current/.¶
InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as "work in progress."¶
This InternetDraft will expire on 9 May 2023.¶
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
1.1. Background
Countries such as the USA, China, and South Korea are adapting to the fifthgeneration mobile communication systems (5G) technology at an increasingly rapid pace. There are more than 1500 cities worldwide with access to 5G technology. Other countries are also taking significant steps to make 5G networks commercially available to their citizens. As the research in 5G technology is moving toward global standardization, it is important for the research community to focus on developing solutions beyond 5G and for the 6G era. The first white paper on 6G [WP6G] was published by 6G Flagship, University of Oulu, Finland under the 6Genesis project in 2019. This white paper identified the key drivers, research requirements, challenges and essential research questions related to 6G. One of the main requirements as listed in this paper was to look at the problem of transmitting data at a speed of over 100 Gbps per user.¶
Additionally, 3GPP requires that the cryptographic algorithms proposed for 5G systems should support 256bit keys [SPEC5G]. Apart from the need of speeds of more than 100 Gbps and supporting 256bit keys, 3GPP also discusses the possible impacts of quantum computing in the coming years, especially due to Grover's algorithm. While describing the impact of quantum computers on symmetric algorithms required for 5G and beyond, 3GPP states the following in Section 5.3 of [SPEC5G]:¶
"The threat to symmetric cryptography from quantum computing is lower than that for asymmetric cryptography. As such there is little benefit in transitioning symmetric algorithms without corresponding changes to the asymmetric algorithms that accompany them."¶
However, it has been shown in numerous articles that quantum computers can be used to either efficiently break or drastically reduce the time necessary to attack some symmetrickey cryptography methods. These results require a serious reevaluation of the premise that has informed beyond 5G quantum security concerns up to this point. Additionally, since NIST will finally standardize quantumresistant public key algorithms in the coming few years, we believe it is important for the research community to also focus on symmetric algorithms for future telecommunications that would provide security against quantum adversaries. The effectiveness of postquantum asymmetric cryptography would only be improved if the symmetric cryptography used with it is also quantum resistant. Thus, a symmetric cryptographic algorithm that¶
 supports 256bit key and provides 256bit security with respect to key recovery and forgery attacks,¶
 has an encryption/decryption speed of more than 100 Gbps, and¶
 is at least as secure as AES256 against quantum adversaries (for 128bit security against a quantum adversary),¶
is needed.¶
Rocca has been designed as an encryption algorithm for a high speed communication such as future internet and beyond 5G mobile communications. Rocca achieves an encryption/decryption speed of more than 100 Gbps in both the raw encryption scheme and the AEAD scheme. It supports a 256bit key and provides 256bit and 128bit security against the key recovery and distinguishing attacks, respectively. The high throughput of Rocca can be achieved by utilizing the AES New Instruction set (AESNI) [AESNI]. Similar approach has been taken by AEGIS family [AEGIS] and Tiaoxin346 [TIAOXIN], both are two submissions to the CAESAR competition [CAESAR]. SNOWV [SNOWV] also uses AES round function as a component so that AESNI can be used.¶
As Rocca has been designed for future telecommunication services, Rocca satisfies two out of three above mentioned requirements. However, there is still room for the improvement with regard to security against quantum computers. This motivates us to propose a symmetrickey algorithm that satisfies all three of the abovementioned requirements. In this document, we propose RoccaS, which is an AESbased encryption scheme with a 256bit key. RoccaS provides both a raw encryption scheme and an AEAD scheme with a 256bit tag. RoccaS is designed to meet the requirements of high throughput of more than 100 Gbps as well as 256bit security. RoccaS achieves an encryption/decryption speed of more than 200 Gbps in both raw encryption scheme and AEAD scheme on Intel(R) Core(TM) i912900K, and can provide 256bit and 128bit security against classical and quantum adversaries respectively.¶
1.2. Design Concept
In this document, we present an AESbased AEAD encryption scheme with a 256bit key and 256bit tag called RoccaS, which is a variant of Rocca described in [ROCCA]. The goal of RoccaS is to further improve the security of Rocca while maintaining its performance advantage.¶
To achieve such a dramatically fast encryption/decryption speed, RoccaS follows the same design principle as Rocca, such as the SIMDfriendly round function and an efficient permutationbased structure. We explore the class of AESbased structures to further increase its speed and reduce the state size. Specifically, we take the following different approaches.¶
 To minimize the critical path of the round function, we focus on the structure where
each 128bit block of the internal state is updated by either one AES round (
aesenc
) or XOR while Jean and Nikolic consider the case of applying bothaesenc
and XOR in a cascade way for one round, and the most efficient structures in [DESIGN] are included in this class.¶  We introduce a permutation between the 128bit state words of the internal state in order to increase the number of possible candidates while maintaining efficiency, because executing such a permutation is a costfree operation in the target software, which was not taken into account in [DESIGN].¶
1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2. Algorithms Description
In this section, the notations and the specification of our designs will be described.¶
2.1. Notations
The following notations will be used in the document. Throughout this document, a block means a 2octet value. For the constants Z0 and Z1, we utilize the same ones as Tiaoxin346 [TIAOXIN].¶

X ^ Y
: The bitwise Exclusive OR (XOR) ofX
andY
.¶ 
X#Y
: For a numberX
and a positive integerY
, theY
th power ofX
.¶ 
f#(N)
: For a functionf
and a nonnegative integerN
, theN
th iteration of functionf
.¶ 
X
: The length ofX
in bits.¶ 
XY
: The concatenation ofX
andY
.¶ 
ZERO(l)
: A zero string of lengthl
bits.¶ 
PAD(X)
:XZERO(l)
, wherel
is the minimal nonnegative integer such thatPAD(X)
is a multiple of 256.¶ 
PADN(X)
:XZERO(l)
, wherel
is the minimal nonnegative integer such thatPADN(X)
is a multiple of 128.¶ 
LE128(X)
: the littleendian encoding of 128bit integer X.¶  Write
X
asX = X[0]X[1] ... X[n] with X[i] = 256
, wheren
isX/256  1
. In addition,X[i]
is written asX[i] = X[i]_0X[i]_1 with X[i]_0 = X[i]_1 = 128
.¶ 
S
: The state of RoccaS, which is composed of 7 blocks, i.e.,S = (S[0], S[1], ..., S[6])
, whereS[i]
(0 <= i <= 6) are blocks andS[0]
is the first block.¶ 
Z0
: A 128bit constant block defined asZ0 = 428a2f98d728ae227137449123ef65cd
.¶ 
Z1
: A 128bit constant block defined asZ1 = b5c0fbcfec4d3b2fe9b5dba58189dbbc
.¶ 
A(X)
: The AES round function without the constant addition operation, as defined below:
A(X) = MixColumns( ShiftRows( SubBytes(X) ) )
, whereMixColumns
,ShiftRows
andSubBytes
are the same operations as defined in AES [AES].¶ 
AES(X,Y)
: One AES round is applied to the blockX
, where the round constant isY
, as defined below:
AES(X,Y) = A(X) ^ Y
.
This operation is the same asaesenc
, which is one of the instructions of AESNI, performs one regular (not the last) round of AES on an input stateX
with a subkeyY
.¶ 
R(S,X0,X1)
: The round function is used to update the state S, as defined in Section 2.2.¶
2.2. The Round Function
The input of the round function R(S,X0,X1)
of RoccaS consists of the state S and two
blocks (X0,X1)
.
If denoting the output by Snew
, Snew:=R(S,X0,X1)
can be defined as follows:¶
Snew[0] = S[6] ^ S[1], Snew[1] = AES(S[0],X_0), Snew[2] = AES(S[1],S[0]), Snew[3] = AES(S[2],S[6]), Snew[4] = AES(S[3],X_1), Snew[5] = AES(S[4],S[3]), Snew[6] = AES(S[5],S[4]).¶
The corresponding illustration can be found in Figure 1.¶
2.3. Specification
RoccaS is an AEAD scheme composed of four phases:
initialization, processing the associated data, encryption and finalization.
The input consists of a 256bit key K = K0K1
,
a nonce N
of between 12 and 16 octets (both inclusive) in length,
the associated data AD
and the message M
,
where K0
and K1
are elements of the binary finite field of 2#128.
The output is the corresponding ciphertext C
and a 256bit tag T
.¶
The settings described below are required for the parameters:¶
 The key
K
MUST be unpredictable for each invocation.¶ 
PADN(N)
, whereN
is the nonce, MUST be unique per invocation with the same key, soN
MUST NOT be randomly generated.¶
2.3.1. Initialization
First, (N,K0,K1)
is loaded into the state S
in the following way:¶
S[0] = K1, S[1] = PADN(N), S[2] = Z0, S[3] = K0, S[4] = Z1, S[5] = PADN(N) ^ K1, S[6] = ZERO(128)¶
Then, 16 iterations of the round function R(S,Z0,Z1)
,
which is written as R(S,Z0,Z1)#(16)
,
are applied to state S
.¶
After 16 iterations of the round function, two 128bit keys are XORed with the state S in the following way:¶
S[0] = S[0] ^ K0, S[1] = S[1] ^ K0, S[2] = S[2] ^ K1, S[3] = S[3] ^ K0, S[4] = S[4] ^ K0, S[5] = S[5] ^ K1, S[6] = S[6] ^ K1.¶
2.3.2. Processing the Associated Data
If AD
is empty, this phase will be skipped. Otherwise,
AD is padded to PAD(AD)
, and the state is updated as follows:¶
for i = 0 to d  1 R(S, PAD(AD)[i]_0, PAD(AD)[i]_1), end for¶
where d = PAD(AD) / 256
.¶
2.3.3. Encryption
The encryption phase is similar to the phase to process the associated data.
If M
is empty, the encryption phase will be skipped.
Otherwise, M
is first padded to PAD(M)
, and then PAD(M)
will be absorbed
with the round function.
During this procedure, the ciphertext C
is generated.
If the last block of M
is incomplete and its length is b
bits, i.e.,
0 < b < 256
, the last block of C
will be truncated to the first b
bits.
A detailed description is shown below:¶
for i = 0 to m  1 C[i]_0 = AES(S[3] ^ S[5], S[0]) ^ PAD(M)[i]_0, C[i]_1 = AES(S[4] ^ S[6], S[2]) ^ PAD(M)[i]_1, R(S, PAD(M)[i]_0, PAD(M)[i]_1), end for¶
where m = PAD(M) / 256
.¶
2.3.4. Finalization
After the above three phases, two 128bit keys K0
and K1
are first XORed with the state S
in the following way:¶
S[1] = S[1] ^ K0, S[2] = S[2] ^ K1.¶
Then, the state S
will again pass through 16 iterations
of the round function R(S,LE128(AD),LE128(M))
and then the 256bit tag T
is computed in the
following way:¶
T = (S[0] ^ S[1] ^ S[2] ^ S[3])  (S[4] ^ S[5] ^ S[6]).¶
2.3.5. RoccaS Algorithm
A formal description of RoccaS can be seen in Figure 2, and the corresponding illustration is shown in Figure 3.¶
2.3.6. A Raw Encryption Scheme
If the phases of processing the associated data and finalization are removed, a raw encryption scheme is obtained.¶
2.3.7. A Keystream Generation Scheme
If the phases of processing the associated data and finalization are removed, and there is no message injection into the round function such that R(S,0,0)
,
a keystream generation scheme is obtained.
This scheme can be used as a general stream cipher and random bit generation.¶
2.3.8. Support for Shorter Key Length
For RoccaS to support 128bit or 192bit keys, the given key needs to be expanded to 256 bits.
When 128bit key is given, it will be set to K0
, and K1
is defined as K1 = ZERO(128)
.
When 192bit key is given, the first 128bit will be set to K0
, and the remaining 64bit will be set to K1_p
.
Then K1
is defined as K1 = K1_pZERO(64)
.¶
Use of Key Derivation Functions (KDF) [KDF] to stretch the key length to 256bit could be another option. The given 128bit or 192bit key will be used as a key derivation key, and the output of the KDF will be 256bit.¶
2.3.9. Settings as AEAD Algorithm Specifications
To comply with the requirements defined in Section 4 of [RFC5116], the settings of the parameters for RoccaS are defined as follows:¶

K_LEN
(key length) is 32 octets (256 bits), andK
(key) does not require any particular data format.¶ 
P_MAX
(maximum size of the plaintext) is 2#125 octets.¶ 
A_MAX
(maximum size of the associated data) is 2#61 octets.¶ 
N_MIN
(minimum size of the nonce) = 12 octets, andN_MAX
(maximum size of the nonce) = 16 octets.¶ 
C_MAX
(the largest possible AEAD ciphertext) = P_MAX + tag length = 2#125 + 32 octets.¶
In addition,¶
2.4. Security Claims
2.4.1. Classic Setting
As described in Section 3, RoccaS provides 256bit security against keyrecovery and forgery attacks in the noncerespecting setting. We do not claim its security in the relatedkey and knownkey settings.¶
The message length for a fixed key is limited to at most 2#128, and we also limit the number of different messages that are produced for a fixed key to be at most 2#128. The length of the associated data for a fixed key is up to 2#64.¶
2.4.2. Quantum Setting
There exist no quantum attacks for keyrecovery and forgery (in noncerespecting setting) on RoccaS with time complexity lower than 2#128. RoccaS does not provide security against relatedkey and knownkey superposition attacks (as is the case of all known block ciphers).¶
3. Security Considerations
3.1. Security Against Attacks
RoccaS is secure against the following attacks:¶
 KeyRecovery Attack: 256bit security against keyrecovery attacks.¶
 Differential Attack: Secure against differential attacks in the initialization phase.¶
 Forgery Attack: 256bit security against forgery attacks.¶
 Integral Attack: Secure against integral attacks.¶

Staterecovery Attack:¶
 The Linear Bias: Secure against a statistical attack.¶
3.2. Other Attacks
While there are many attack vectors for block ciphers, their application to RoccaS is restrictive, as the attackers can only know partial information about the internal state from the ciphertext blocks. In other words, reversing the round function is impossible in RoccaS without guessing many secret state blocks. Therefore, only the above potential attack vectors are taken into account. In addition, due to the usage of the constant (Z0,Z1) at the initialization phase, the attack based on the similarity in the four columns of the AES state is also excluded.¶
3.3. Nonce Reuse
Inadvertent reuse of the same nonce by two invocations of the RoccaS encryption operation, with the same key, undermines the security of the messages processed with those invocations. A loss of confidentiality ensues because an adversary will be able to reconstruct the bitwise exclusiveor of the two plaintext values.¶
4. IANA Considerations
IANA has assigned value TBD in the AEAD Algorithms registry to AEAD_ROCCA.¶
5. References
5.1. Normative References
 [RFC2119]
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfceditor.org/info/rfc2119>.
 [RFC5116]
 McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <https://www.rfceditor.org/info/rfc5116>.
 [RFC8174]
 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfceditor.org/info/rfc8174>.
5.2. Informative References
 [AEGIS]
 Preneel, B., "AEGIS: A fast authenticated encryption algorithm", Selected Areas in Cryptography (SAC 2013) pp.185201, .
 [AES]
 National Institute of Standards and Technology, "FIPS 197 Advanced Encryption Standard (AES)", , <https://doi.org/10.6028/NIST.FIPS.197>.
 [AESNI]
 Gueron, S., "Intel Advanced Encryption Standard (AES) New Instructions Set", , <https://www.intel.com/content/dam/doc/whitepaper/advancedencryptionstandardnewinstructionssetpaper.pdf>.
 [CAESAR]
 "CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness", , <https://competitions.cr.yp.to/caesar.html>.
 [DESIGN]
 Jean, J. and I. Nikolic, "Efficient Design Strategies Based on the AES Round Function", In: Peyrin, T. (eds) Fast Software Encryption. FSE 2016. Lecture Notes in Computer Science, vol 9783, , <https://doi.org/10.1007/9783662529935_17>.
 [KDF]
 Chena, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", NIST Special Publication 800108, , <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800108.pdf>.
 [ROCCA]
 Sakamoto, K., Liu, F., Nakano, Y., Kiyomoto, S., and T. Isobe, "Rocca: An Efficient AESbased Encryption Scheme for Beyond 5G", IACR Transactions on Symmetric Cryptology, 2021(2), 130, , <https://doi.org/10.46586/tosc.v2021.i2.130>.
 [SNOWV]
 Ekdahl, P., Johansson, T., Maximov, A., and J. Yang, "A new SNOW stream cipher called SNOWV", IACR Transactions on Symmetric Cryptology, 2019(3), 142, , <https://doi.org/10.13154/tosc.v2019.i3.142>.
 [SPEC5G]
 3GPP SA3, "Study on the support of 256bit algorithms for 5G", , <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3422>.
 [TIAOXIN]
 Nikolic, I., "Tiaoxin346: VERSION 2.0", CAESAR Competition, , <https://competitions.cr.yp.to/round2/tiaoxinv2.pdf>.
 [WP6G]
 Latvaaho, M. and K. Leppaenen, "Key drivers and research challenges for 6G ubiquitous wireless intelligence", .
Appendix A. Software Implementation
A.1. Implementation with SIMD Instructions
Figure 4 shows a sample implementation of RoccaS.¶
A.2. Test Vector
This section gives three test vectors of RoccaS. The least significant octet of the vector is shown on the left and the first 128bit value is shown on the first line.¶
=== test vector #1=== key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nonce = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 associated data = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 plaintext = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ciphertext = 9a c3 32 64 95 a8 d4 14 fe 40 7f 47 b5 44 10 50 24 81 cf 79 ca b8 c0 a6 69 32 3e 07 71 1e 46 17 0d e5 b2 fb ba 0f ae 8d e7 c1 fc ca ee fc 36 26 24 fc fd c1 5f 8b b3 e6 44 57 e8 b7 e3 75 57 bb tag = 8d f9 34 d1 48 37 10 c9 41 0f 6a 08 9c 4c ed 97 91 90 1b 7e 2e 66 12 06 20 2d b2 cc 7a 24 a3 86 === test vector #2=== key = 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 nonce = 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 associated data = 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 plaintext = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ciphertext = 55 9e cb 25 3b cf e2 6b 48 3b f0 0e 9c 74 83 45 97 8f f9 21 03 6a 6c 1f dc b7 12 17 28 36 50 4f bc 64 d4 30 a7 3f c6 7a cd 3c 3b 9c 19 76 d8 07 90 f4 83 57 e7 fe 0c 06 82 62 45 69 d3 a6 58 fb tag = b7 30 e6 b6 19 f6 3c cf 7e 69 73 59 14 d7 6a b5 2f 70 36 0c 8a 65 4b ad 99 13 20 ef 95 2c 40 a2 === test vector #3=== key = 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef nonce = 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef associated data = 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef plaintext = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ciphertext = b5 fc 4e 2a 72 b8 6d 1a 13 3c 0f 02 02 bd f7 90 af 14 a2 4b 2c db 67 6e 42 78 65 e1 2f cc 9d 30 21 d1 84 18 fc 75 dc 19 12 dd 2c d7 9a 3b ee b2 a9 8b 23 5d e2 29 9b 9d da 93 fd 2b 5a c8 f4 36 tag = 32 6e 63 57 e5 00 34 a7 75 0f c2 01 31 aa 6f 76 19 ed 23 db 5b da d0 00 28 20 cc 70 7f 35 9f 8d¶
Acknowledgements
This draft is partially supported by a contract of "Research and development on new generation cryptography for secure wireless communication services" among "Research and Development for Expansion of Radio Wave Resources (JPJ000254)", which was supported by the Ministry of Internal Affairs and Communications, Japan.¶