idnits 2.17.1 draft-mcgrew-aero-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1366 has weird spacing: '...archive http:...' == Line 1410 has weird spacing: '...archive http:...' -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'S-X' is mentioned on line 165, but not defined == Missing Reference: 'S-Z' is mentioned on line 626, but not defined == Unused Reference: 'FIPS197' is defined on line 1373, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft J. Foley 4 Intended status: Standards Track Cisco Systems 5 Expires: August 18, 2014 February 14, 2014 7 Authenticated Encryption with Replay prOtection (AERO) 8 draft-mcgrew-aero-01.txt 10 Abstract 12 This document describes Authenticated Encryption with Replay 13 prOtection (AERO), a cryptographic technique that provides all of the 14 essential security services needed for communication security. AERO 15 offers several advantages over other methods: it has more compact 16 messages, provides stronger misuse resistance, avoids the need to 17 manage implicit state, and is simpler to use. This document defines 18 a particular AERO algorithm as well as a registry for such 19 algorithms. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 18, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 3 57 1.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Data types and notation . . . . . . . . . . . . . . . . . 5 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Problems addressed by AERO . . . . . . . . . . . . . . . . 6 61 3. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. Encryption Initialization . . . . . . . . . . . . . . . . 9 63 3.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3. Decryption Initialization . . . . . . . . . . . . . . . . 10 65 3.4. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.5. Multiple senders and multiple receivers . . . . . . . . . 10 67 3.6. AEAD interface . . . . . . . . . . . . . . . . . . . . . . 11 68 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.2. Encryption Initialization . . . . . . . . . . . . . . . . 13 71 4.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.4. Decryption Initialization . . . . . . . . . . . . . . . . 14 73 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 15 74 5. Stateless encryption algorithms . . . . . . . . . . . . . . . 17 75 5.1. Wide PRP (WPRP) . . . . . . . . . . . . . . . . . . . . . 17 76 5.1.1. WPRP Requirements and survey . . . . . . . . . . . . . 19 77 5.2. Other cryptographic techniques . . . . . . . . . . . . . . 19 78 6. Loss, reorder, and resynchronization . . . . . . . . . . . . . 21 79 7. Usage and applicability . . . . . . . . . . . . . . . . . . . 23 80 8. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 11. Security considerations . . . . . . . . . . . . . . . . . . . 27 84 11.1. Authentication and confidentiality . . . . . . . . . . . . 28 85 11.1.1. Authentication strength . . . . . . . . . . . . . . . 30 86 11.2. Length hiding . . . . . . . . . . . . . . . . . . . . . . 30 87 11.3. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 30 88 11.4. Multiple senders . . . . . . . . . . . . . . . . . . . . . 31 89 11.5. Sequence number management failure . . . . . . . . . . . . 32 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 92 13.1. Normative references . . . . . . . . . . . . . . . . . . . 34 93 13.2. Informative references . . . . . . . . . . . . . . . . . . 34 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 96 1. Introduction 98 This document describes Authenticated Encryption with Replay 99 prOtection (AERO), a cryptographic technique that provides all of the 100 essential security services needed for communication security. 102 AERO can be considered a stateful and self-synchronizing 103 authenticated encryption method that provides protection from replay 104 attacks as a side benefit. Replay protection and authentication are 105 provided through a single mechanism, in which a sequence number is 106 encrypted along with a plaintext message. If the ciphertext message 107 is not tampered with, then this sequence number will be recovered by 108 the decrypter, and verified to be valid. If the ciphertext message 109 is a replay of an earlier message, then the decrypter will detect 110 this fact from the recovered sequence number. If the ciphertext 111 message is tampered with, or is crafted as a forgery, this fact will 112 be apparent to the decrypter because the value that should be a valid 113 sequence is instead a pseudorandom value. 115 AERO makes use of an underlying stateless encryption algorithm. This 116 note defines a set of AERO algorithms that are based on an underlying 117 Wide Pseudo-Random Permutation (WPRP). AERO is not, by itself, a 118 block cipher mode of operation. 120 This note is structured as follows. Section 1 introduces the basic 121 idea of AERO, describes the conventions and notations used in this 122 note, and provides a glossary of acronyms and variables. Section 2 123 provides background on the problems that AERO solves. The interface 124 and implementation are presented in Section 3 and Section 4, 125 respectively. The underlying cryptographic primitives are described 126 in Section 5. Section 6 describes synchronization between encrypters 127 and decrypters, and Section 7 describes usage. A rationale for the 128 design details is offered in Section 8, and test considerations and 129 test cases are presented in Section 9. IANA considerations and 130 security considerations follow in Section 10 and Section 11, 131 respectively. 133 1.1. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 1.2. Glossary 141 This section describes the symbols and acronyms used in this 142 document. 144 A - Associated Data. An unencrypted value whose integrity and 145 authenticity is to be protected. 147 AERO - Authenticated Encryption with Replay prOtection. A 148 cryptographic technique that combines the three security services 149 essential to communication security. 151 C - Ciphertext. An encrypted value that corresponds to a 152 plaintext. 154 FAIL - a value returned by the AERO decryption operation to 155 indicate that a ciphertext message is not valid; it could be 156 either a replay or a forgery attempt. 158 K - Key. A secret key that is shared between the sender(s) and 159 receiver(s). 161 M - bitmask. A bit vector used by the AERO decryption algorithm 162 that holds information about the sequence numbers that have 163 already been accepted. If a message with the sequence number X 164 has been accepted and the current sequence number S > X, then 165 M[S-X] = 1; otherwise M[S-X] = 0. 167 P - Plaintext. An unencrypted value whose confidentiality, 168 integrity and authenticity is to be protected. 170 PMIN - minimum number of bytes of plaintext for a stateless 171 encryption algorithm. PMIN is a parameter of the stateless 172 encryption algorithm, which is used in the padding logic. 174 R - the last rejected candidate sequence number that is greater 175 than the current sequence number S. A T-bit unsigned integer 176 maintained by the AERO decryption algorithm. 178 S - the current sequence number. A T-bit unsigned integer 179 maintained by the AERO encryption algorithm, where it represents 180 the sequence number of the next message to be encrypted, and by 181 the AERO decryption algorithm, where it represents the last 182 candidate sequence number that was accepted. 184 T - The number of bits in the sequence number that is internal to 185 AERO encryption and decryption. 187 W - Reorder tolerance parameter. A parameter used in AERO 188 decryption (but not encryption) that determines the amount of 189 message loss or reorder that the algorithm will tolerate. This 190 value is 64 by default, but other values may be used as well. 192 V - Resynchronization parameter. A parameter that determines the 193 amount of message loss or reorder that the AERO decryption 194 algorithm will tolerate during resynchronization. This value is 8 195 by default, but other values may be used as well. 197 Z - the candidate sequence number. A value used in AERO 198 decryption that may be a sequence number, or alternately may be 199 data that resulted from the actions of an attacker. 201 1.3. Data types and notation 203 An octet string is an ordered sequence of eight-bit values. Note 204 that these strings are not character strings, and issues such as 205 character representation are out of scope for this note. 207 len(X) denotes the number of bits in the string X, expressed as an 208 unsigned integer in network byte order. 210 The concatenation of two octet strings A and B is denoted as A || B 212 Conversion between unsigned integers and octet strings is done as 213 follows. The Integer to String (I2S) algorithm takes as input an 214 unsigned integer U, and converts it to network byte order (that is, a 215 big-endian representation, in which the most significant octet is the 216 initial one), and then returns the resulting octet string. The 217 String to Integer (S2I) algorithm takes as input an octet string S, 218 considers it as an integer in network byte order, and then converts 219 it into the internal representation for unsigned integers used by the 220 system. 222 2. Background 224 Authenticated encryption [BN00] is a form of encryption that, in 225 addition to providing confidentiality for the plaintext that is 226 encrypted, provides a way to check its integrity and authenticity. 227 Authenticated Encryption with Associated Data, or AEAD [R02], adds 228 the ability to check the integrity and authenticity of some 229 Associated Data (AD), also called "additional authenticated data", 230 that is not encrypted. 232 AEAD is used in many communication security protocols, such as ESP, 233 TLS, DTLS, IKE, and SRTP. These protocols also incorporate replay 234 protection using an sequence number that is carried in the packet, 235 which is authenticated because it is part of the associated data. 236 This security service enables the receiver of a message to detect 237 when a received message is a duplicate of a previously received 238 message. 240 In order to minimize the data overhead, some protocols (such as SRTP 241 and ESP) have the most significant part of the sequence number (that 242 is, the high order bits) be implicit state, which is not sent on the 243 wire. The receiver constructs an estimate of the sequence number 244 from the data on the wire and its current state. 246 Authenticated Encryption with Replay prOtection (AERO) extends AEAD 247 so that it provides a replay protection service. It also enables a 248 receiver to correctly sequence all of the messages that it receives 249 into the same order that they were sent. A replay protection service 250 has a reorder tolerance parameter W; if a receiver processes a 251 message that is more than W messages earlier than a previously 252 processed message, then the service will reject the message even if 253 it is not a replay. 255 2.1. Problems addressed by AERO 257 Many communication security protocols are operated in environments 258 where bandwidth is a scarce resource, and thus they seek to minimize 259 the data overhead, that is, the number of additional bytes that must 260 be communicated in order to add confidentiality, authenticity, and 261 replay protection to each message. To authenticate a message, 262 lengthening it is unavoidable. However, traditional encryption and 263 replay protection techniques add avoidable overhead. Encryption 264 methods methods such as AES-CBC encryption [SP800-38] have an average 265 overhead of 24 bytes, and many uses of CTR, GCM [GCM], and CCM [CCM] 266 have eight bytes of overhead because a nonce is carried in each 267 message. In addition to that overhead, replay protection typically 268 adds its own overhead; the use of a four-byte sequence number, for 269 instance, adds that number of bytes. 271 Some communication security protocol uses an implicit or partly 272 implicit sequence number to reduce overhead. This practice 273 complicates the use of that protocol whenever there are multiple 274 receivers, since it is necessary to (securely) communicate the 275 current value of the implicit part of the sequence number to a new 276 receiver at the time that the receiver joins the session. For 277 instance, [RFC4771] furnishes an example of the complications 278 introduced by the need to manage implicit state. 280 Several cryptographic algorithms require that a distinct nonce is 281 input into each invocation of the encryption algorithm. This 282 requirement is difficult to satisfy if there are multiple senders, or 283 multiple encryption units, using the same secret key. Algorithms 284 that require nonces introduce significant complexity into the systems 285 that use them, as is revealed by the survey of usage of and issues 286 with nonces in Internet protocols [IV-GEN]. One of the cannons of 287 computer security is that "input is evil", that is, data that is 288 accepted into a security module might be manipulated by an attacker 289 and thus should not be trusted until it has been validated. A 290 cryptographic algorithm that accepts a nonce and requires it to be 291 distinct introduces an opportunity for an attacker to defeat security 292 through "evil" influence of that input. 294 Several cryptographic algorithms that require a distinct nonce as an 295 input have a serious security degradation if there is nonce misuse 296 (that is, if a system failure results in two or more identical nonces 297 being used for the same key). CTR, CCM, and GCM all have a loss of 298 confidentiality for each message that is associated with a misused 299 nonce. GCM, GMAC [GCM], UMAC [RFC4418], and POLY1305 leak their 300 authentication keys after nonce misuse. In scenarios in which it is 301 not possible to provide high assurance that nonces will not be 302 misused, these algorithms may not be appropriate. 304 Both dedicated authenticated encryption algorithms, and the 305 traditional method of combination of separate authentication and 306 encryption algorithms, are often complex to use. Nonces and 307 initialization vectors, especially, are often a source of confusion 308 for implementers and application designers. 310 AERO solves these problems by using a technique that combines message 311 authentication with replay protection, thus eliminating the data 312 overhead associated with replay protection and any need for using 313 implicit state. AERO does not use a nonce as input, which addresses 314 multiple issues: it reduces data overhead, it avoids all of the 315 problems of coordinating nonces and the potential problems of nonce 316 misuse, and it simplifies the jobs of the designers and implementers 317 of applications and protocols. AERO can easily be used in multiple- 318 sender scenarios, because no coordination of nonces is needed, and in 319 multiple-receiver scenarios, because no coordination of implicit 320 state is needed. 322 3. Interface 324 An AERO algorithm has four operations: encryption, decryption, 325 encryption initialization, and decryption initialization. The inputs 326 and outputs of these algorithms are defined below in terms of octet 327 strings. An octet string is an ordered sequence of eight-bit values. 329 The terms "AERO encryption" and "AERO decryption" refer to algorithms 330 that provide authenticated encryption with replay protection. For 331 brevity, these algorithms are simply called "encryption" and 332 "decryption" when AERO is clear from the context. 334 An implementation MAY accept additional inputs to these algorithms. 335 For example, an optional input could be provided to allow the user to 336 select between different implementation strategies. However, such 337 extensions MUST NOT affect interoperability with other 338 implementations. 340 3.1. Encryption Initialization 342 The encryption initialization operation has one input: 344 A secret key K, which MUST be generated in a way that is uniformly 345 random or pseudorandom. This input is an octet string. The 346 number of octets in K is fixed for each AERO algorithm, and is 347 between 1 and 255. 349 The operation has a single output, an AERO encryption context. 351 3.2. Encryption 353 The AERO encryption operation has three inputs, each of which is an 354 octet string: 356 An AERO encryption context. 358 A plaintext P, which contains the data to be encrypted and 359 authenticated. The number of octets in P MAY be zero. 361 The associated data A, which contains the data to be 362 authenticated, but not encrypted. The number of octets in A MAY 363 be zero. 365 There is a single output: 367 A ciphertext C, which is an octet string that is at least as long 368 as the plaintext. 370 A plaintext P and its associated data A is sometimes denoted together 371 as (A, P), and that pair of elements is called a plaintext message. 372 Similarly, a ciphertext C and its associated data A is denoted 373 together as (A, C), and is called a ciphertext message. 375 3.3. Decryption Initialization 377 The decryption initialization operation has one or two inputs: 379 A secret key K, which MUST match the secret key used in the 380 corresponding encryption initialization. This input is an octet 381 string. 383 The reorder tolerance parameter W, a non-negative integer which 384 indicates the amount of reorder of messages that must be 385 tolerated. This input is optional; when it is not provided as an 386 input, the default value of 64 SHOULD be used. 388 The operation has a single output, an AERO decryption context. 390 3.4. Decryption 392 The AERO decryption operation has three inputs, each of which is an 393 octet string: 395 An AERO decryption context. 397 An octet string C. 399 The associated data A, which contains the data to be 400 authenticated, but not encrypted. The length of A MAY be zero. 402 The output is one of these two alternatives: 404 An octet string P and an unsigned integer indicating the order in 405 which P appeared in the sequence of plaintexts input to the send 406 algorithm, or 408 The symbol FAIL, which indicates that either the value C was not 409 output by the send algorithm, or that (A, C) matches a previously 410 accepted pair of values. 412 3.5. Multiple senders and multiple receivers 414 A communications security protocol may have multiple senders 415 (encrypters) as well as multiple receivers (decrypters). A single 416 AERO key MAY be used by multiple senders, in which case each sender 417 MUST use a distinct AERO encryption context. 419 When multiple AERO encryption contexts are in use for a single key, a 420 receiver must use a distinct AERO decryption context to process the 421 messages encrypted with each distinct encryption context. That is, 422 the receiver maintains a decryption context for each sender. This 423 matches the conventional practice of communication security 424 protocols, in which the receiver maintains a distinct security 425 association for each sender. 427 When processing a protected message, a receiver needs to select the 428 appropriate AERO context to use in processing that message. Thus, 429 each protected message must be associated with some indication of its 430 sender. We call a field that contains this indication a Sender 431 IDentifier (SID). 433 When there are multiple senders, the values of the associated data 434 input to the encryption algorithm for different senders SHOULD be 435 distinct. This practice ensures that no two messages are identical, 436 and that fact ensures that the AERO system provides strong 437 confidentiality. An easy way to ensure the distinctness of 438 Associated Data values is to include an SID in those values. For 439 example, this requirement is met if the associated data includes a 440 message header, and that header contains a field that identifies the 441 sender of the message. Alternatively, the value of the plaintext can 442 be distinct for each sender, for instance, if each plaintext includes 443 an SID. 445 If senders accidentally use the same SID value, the security of the 446 session will degrade, but not catastrophically. See section 447 Section 11.4 for more details. 449 3.6. AEAD interface 451 AERO can be used through the IETF standard interface for 452 authenticated encryption with associated data [RFC5116]. As AERO 453 does not use a nonce or initialization vector, N_MAX = N_MIN = 0, and 454 the application using the AEAD interface need not provide a nonce. 455 Note that most of the usage guidance in RFC 5116 describes 456 stipulations and cautions on the use of the nonces, so by eliminating 457 the need for a nonce, AERO is simplifying the use of this standard. 459 4. Implementation 461 AERO makes use of a technique that combines message authentication 462 with replay protection, in which the sender maintains a sequence 463 number, and the encrypted value of this sequence number is 464 communicated to the receiver. When the receiver decrypts a message, 465 it parses out the data that would be equal to a sequence number if 466 the message was sent by a legitimate sender, and verifies that this 467 data is sensible. This data is called a candidate sequence number, 468 and is denoted as Z; the verification process is detailed below. If 469 the data is not sensible, then the decryption algorithm rejects the 470 message. The technique provides authenticity because Z is a 471 pseudorandom function of both the ciphertext and associated data, and 472 in a forgery attempt, Z will be rejected with overwhelming 473 probability. 475 AERO is a stateful encryption method. It makes use of an underlying 476 stateless encryption method; the interface to this method is defined 477 below. This interface allows an AERO implementation to separate out 478 the authentication and replay protection logic from the cryptographic 479 algorithms that provide pseudorandomness. The interface also 480 facilitates the use of different cryptographic techniques, thus 481 allowing algorithm agility. 483 The stateless encryption algorithm takes as input a secret key K, a 484 plaintext P, a T-bit unsigned integer S, and an associated data A, 485 and returns a ciphertext C. Here K, A, P, and C are all octet 486 strings. 488 The stateless decryption algorithm takes as input a secret key K, a 489 ciphertext C, and an associated data A, and returns a plaintext P and 490 a T-bit unsigned integer U. 492 The stateless encryption algorithm may not be able to encrypt 493 plaintexts that are shorter than a certain minimum value, so 494 plaintexts are lengthend with the "pad" routine prior to encryption, 495 and padding is removed after decryption with the "strip" routine. We 496 denote as PMIN the minimum number of bytes in a plaintext that the 497 stateful encryption algorithm can accept. 499 Note that the stateless encryption provides only confidentiality, and 500 not authenticity. 502 4.1. Contexts 504 An encryption context includes a T-bit unsigned integer that holds 505 the sequence number S. 507 A decryption context includes a W-bit bitmask M and two T-bit 508 unsigned integers S and R, which record the highest candidate 509 sequence number that has been accepted, and the last candidate 510 sequence number that has been rejected, respectively. 512 4.2. Encryption Initialization 514 The encryption initialization operation does the following: 516 1. S is initialized to zero. 518 2. The value of the secret key K is stored in the context. 520 4.3. Encryption 522 To encrypt a message (A, P), the following steps are performed: 524 1. The current sequence number S is read from the context. If S is 525 greater than 2^T - 1, then the context cannot be used to encrypt 526 any messages, so an indication of this error state is returned 527 and the encryption processing halts. Otherwise, processing 528 continues as follows. 530 2. U is set to the value of a S converted from an unsigned integer 531 to an octet string using the Integer to String (I2S) routine 532 described in Section 1.3. 534 3. If PMIN * 8 > T, then P is lengthened by appending a padding 535 string PS to it, to ensure that L = len(P) + len(PS) + T is at 536 least 128. The value of PS is as follows: 538 PS = 00 if len(P) + T >= 120, 539 PS = 0101 if len(P) + T = 112, 540 PS = 020202 if len(P) + T = 104, 541 PS = 03030303 if len(P) + T = 96, 542 PS = 0404040404 if len(P) + T = 88, 543 PS = 050505050505 if len(P) + T = 80, 544 PS = 06060606060606 if len(P) + T = 72, 545 PS = 0707070707070707 if len(P) + T = 64, 546 PS = 080808080808080808 if len(P) + T = 56, 547 PS = 09090909090909090909 if len(P) + T = 48, 548 PS = 0A0A0A0A0A0A0A0A0A0A0A if len(P) + T = 40, 549 PS = 0B0B0B0B0B0B0B0B0B0B0B0B if len(P) + T = 32, 550 PS = 0C0C0C0C0C0C0C0C0C0C0C0C0C if len(P) + T = 24, 551 PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) + T = 16, 552 PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) + T = 8. 554 Note that padding MUST be appended to the plaintext if 555 PMIN * 8 > T, and otherwise padding MUST NOT be used. As the 556 parameter T is fixed for each particular key, either all of the 557 messages processed by a particular key will use padding, or all 558 will not. 560 4. The stateless encryption algorithm is applied to U, P, and A, 561 using the secret key from the context. 563 5. The sequence number in the context is incremented by one. 565 6. The ciphertext C resulting from the stateless encryption 566 algorithm is returned. 568 A P 569 +----|------|------------------+ 570 | | | | 571 | | | +------+ | 572 | | | | | | 573 | | | v +----+ | 574 | | | S ->| +1 | | 575 | | | | +----+ | 576 | | v v | 577 | | +-----+ +-----+ | AERO 578 | | | pad | | I2S | | encryption 579 | | +-----+ +-----+ | 580 | | | | | 581 | v v v | 582 | +------------------+ | 583 K ---->| stateless | | 584 | | encryption | | 585 | +------------------+ | 586 | | | 587 +-----------|------------------+ 588 v 589 C 591 Figure 1: An illustration of the AERO encryption process. 593 4.4. Decryption Initialization 595 During the decryption initialization process, 597 1. S is initialized to the reorder tolerance parameter W, 599 2. R is initialized to 2^T - 1, and 600 3. the bitmask M is initialized to the all-zero value. 602 4.5. Decryption 604 To decrypt an encrypted message (A, C), 606 1. The stateless decryption algorithm is applied to A and C, using 607 the secret key K in the context, returning a candidate sequence 608 number Z, which is a T-bit unsigned integer, and a plaintext Q, 609 which is an octet string. 611 2. If PMIN * 8 > T, then padding is removed from Q as follows. B is 612 set to the value of the last octet of Q, converted to an 8-bit 613 unsigned integer. If B > (128 - T)/8, then the FAIL symbol is 614 returned, and processing halts. Otherwise, the octet string P is 615 set to all but the final B + 1 octets of Q. 617 3. Z is converted from an octet string to an unsigned integer using 618 the S2I routine defined in Section 1.3. 620 4. Z is processed as follows; see Figure 3 for an illustration. 622 1. If Z is between 0 and S-W, inclusive, then Z is rejected. 624 2. If Z is between S-W+1 and S, inclusive, then the bitmask M is 625 checked. If M[S-Z] = 0, then Z is accepted, M[S-Z] is set to 626 1, and P is returned as the plaintext. If M[S-Z] = 1, then Z 627 is rejected. 629 3. If Z is between S+1 and S+W, inclusive, then Z is accepted, S 630 is set to Z, and P is returned as the plaintext. The bitmask 631 is shifted by Z-S (in the direction of higher indicies). 633 4. If Z is between S+W+1 and R, inclusive, then Z is rejected 634 and R is set to Z. 636 5. If Z is between R+1 and R+V, inclusive, then Z is accepted, S 637 is set to Z, the bitmask M is set to the all-zero value, and 638 P is returned as the plaintext. 640 6. If Z is between R+V+1 and 2^T+1, inclusive, then Z is 641 rejected and R is set to Z. 643 5. When Z is rejected, then AERO decryption MUST return the FAIL 644 symbol, which indicates that either the message was a replay or a 645 forgery attempt. 647 A C 648 +------|-------|--------------+ 649 | v v | 650 | +-------------+ | 651 K ---->| stateless | | 652 | | decryption | | 653 | +-------------+ | 654 | | | | 655 | v v | 656 | +-----+ +-----+ | 657 | |strip| | S2I | | 658 | +-----+ +-----+ | AERO 659 | | | | decryption 660 | v v | 661 | P Z | 662 | | | 663 | v | 664 | +-------------+ | 665 | S-->| check |<--R | 666 | ^ +-------------+ ^ | 667 | | | | | | 668 | +----------+ +----------+ | 669 | | accept | | reject | | 670 | +----------+ +----------+ | 671 | | | | 672 +--------|-----------|--------+ 673 v v 674 P (or) FAIL 676 Figure 2: An illustration of the AERO decryption process. 678 check reject reject 679 bitmask and and 680 | set R to Z set R to Z 681 reject | accept | accept | 682 | | | | | | 683 v v v v v v 684 +---------+----+----+----------------+---+----------------+-> Z 685 | | | | | | | 686 0 S-W S S+W R R+V 2^T-1 688 Figure 3: An illustration of how the candidate sequence number Z is 689 processed during AERO decryption. The possible values of Z are shown 690 on a number line from 0 to 2^T-1. S and R are taken from the 691 decryption context, the region into which Z falls determines how 692 that value is processed. The acceptance region between R and R+V 693 provides resynchronization as described in Section 6. 695 5. Stateless encryption algorithms 697 5.1. Wide PRP (WPRP) 699 An Pseudo-Random Permutation (PRP) is a keyed function that is both 700 invertible and pseudorandom; that is, when the key is chosen at 701 random, an attacker cannot distinguish it from an invertible function 702 selected at random. For instance, a block cipher is a PRP with a 703 fixed length (and narrow) input and output. 705 An encryption algorithm that accepts plaintexts that have varying 706 lengths can also be a PRP. This type of algorithm is called a Wide 707 Pseudo-Random Permutation (WPRP), because the inputs can be wider 708 than those of a typical block cipher. For our purposes, the WPRP 709 must also accept an associated data input. For each distinct value 710 of the associated data, the WPRP must realize a distinct pseudorandom 711 function. Informally, for each distinct value of A, the WPRP "looks 712 like" a distinct PRP. 714 A WPRP is used as the underlying stateful encryption encryption 715 method as follows. To encrypt an associated data A, a plaintext P, 716 and a sequence number U with a secret key K, first U is appended to 717 P, and the WPRP encryption is performed with the key K, the 718 associated data A, and the plaintext Q = P || U resulting from the 719 concatenation of P and U. The output of the WPRP encryption is 720 returned as the ciphertext. This process is shown in Figure 4. 722 A P U 723 +------|-----|----|-----+ 724 | | | | | 725 | | v v | 726 | | +--------+ | 727 | | | append | | 728 | | +--------+ | stateless 729 | | | | encryption 730 | | v | 731 | | Q | 732 | | | | 733 | v v | 734 | +-----------------+ | 735 K ---->| WPRP encryption | | 736 | +-----------------+ | 737 | | | 738 +-----------|-----------+ 739 v 740 C 742 Figure 4: Using a WPRP as a stateless encryption method in AERO. 744 To decrypt a ciphertext C with associated data A with a secret key K, 745 first the WPRP decryption is applied to C, using the key K. Then the 746 resulting output Q is split into two separate octet strings. The 747 final T bits of the output is returned as U, and the initial len(Q) - 748 T bits of Q are returned as P. This process is shown in Figure 5. 750 A C 751 +------|-------|--------+ 752 | | | | 753 | | | | 754 | v v | 755 | +-----------------+ | 756 K ---->| WPRP decryption | | 757 | +-----------------+ | 758 | | | 759 | v | 760 | Q | stateless 761 | | | decryption 762 | v | 763 | +-------+ | 764 | | split | | 765 | +-------+ | 766 | | | | 767 +-----------|-----|-----+ 768 v v 769 P U 771 Figure 5: Using a WPRP as a stateless decryption method in AERO. 773 A WPRP has the property that each bit of its output is a pseudorandom 774 function of each bit of both of its inputs, for both encryption and 775 decryption. A WPRP is very well suited for use in AERO. The fact 776 that encryption is a WPRP, combined with the use of a sequence 777 number, ensures strong confidentiality of the plaintext. The fact 778 that the decryption algorithm is a WPRP ensures that an attacker 779 cannot predict (much less control) the candidate sequence number, 780 thus ensuring strong integrity, authenticity, and replay protection. 782 WPRPs are used in disk-block encryption [1619.2], because they 783 provide the best security possible in scenarios where the ciphertext 784 cannot be any longer than the plaintext. 786 When a WPRP algorithm is used as the EAD algorithm in AERO, we call 787 the resulting combination AERO-WPRP. An AERO-WPRP algorithm has very 788 strong security properties, as described in Section 11. 790 5.1.1. WPRP Requirements and survey 792 There are many WPRP designs in the cryptographic literature, driven 793 largely by interest in disk-block encryption. However, AERO has some 794 requirements that are different from those of disk-block encryption. 795 Most importantly, the WPRP encryption algorithm must be able to 796 process plaintexts that vary in length, using a single key. (In 797 contrast, all of the blocks in a disk typically have the same length, 798 allowing a WPRP design to be optimized for a fixed size.) 800 The Advanced Encryption Standard (AES) eXtended Code Book (XCB) mode 801 of operation, or AES-XCB [MF07], is a WPRP that can accept plaintexts 802 with lengths of 16 bytes or higher. Internally, it roughly consists 803 of a layer of hashing, followed by a layer of counter mode, followed 804 by another layer of hashing, with a small amount of additional 805 processing. It was first introduced in 2004, and a second version 806 was introduced in 2007, and was standardized in the IEEE [1619.2]. 807 Recent work has raised questions about the security of the second 808 version when used in scenarios in which the lengths of the plaintexts 809 vary, which would make it inappropriate for AERO. 811 Chakraborty and Sarkar presented HCH, an improved hash-couter-hash 812 WPRP mode of operation in 2007, which reduces the amount of 813 additional processing and improves the security bound, so that more 814 data can be securely encrypted for a fixed key [CS07]. 816 Sarkar introduced yet another improvement in WPRPs in 2007, 817 presenting a mode of operation based on a hash-encrypt-hash design 818 [S07]. 820 5.2. Other cryptographic techniques 822 Using a Wide PRP in AERO provides very strong security. However, it 823 is more computationally expensive than some other approaches. Thus, 824 it may be useful to use other techniques that trade some well- 825 understood reduction in security properties for lessened 826 computational cost. We do not define any such techniques in this 827 note, but we outline the tradeoffs that are possible. 829 AEAD algorithms fit into two distinct categories: online and offline. 830 With an online encryption algorithm, the ith ciphertext block can be 831 output before the (i+1)st plaintext block has to be read (where a 832 block is the size of the data blocks processed by a block cipher, 833 typically) . These algorithms make a single pass over the data, and 834 implementations need not buffer a significant amount of state. In 835 contrast, with an offline encryption algorithm the entire plaintext 836 must be read in before the first block of ciphertext can be output. 837 Such algorithms must store state equal in length to the plaintext or 838 ciphertext that they are processing. In a software environment, an 839 offline algorithm is acceptable, as long it processes only plaintexts 840 with lengths are short enough that they fit into high-speed random 841 access memory. However, offline algorithms cannot be implemented in 842 a hardware pipeline, such as those used in high-speed network 843 encryption (for protocols such as 802.1AE). 845 A WPRP is necessarily an offline algorithm. However, an online 846 algorithm can implement a weakened variant of a WPRP: an Online 847 Pseudo-Random Permutation (OPRP). An online permutation is a length- 848 preserving permutation such that the ith block of output depends only 849 on the first i blocks of input, for all values of i. An OPRP is an 850 keyed online permutation that a computationally limited attacker 851 cannot distinguish from an online permutation chosen uniformly at 852 random from the set of all online permutations. With an OPRP, an 853 attacker will be able to recognize when two messages with common 854 plaintext prefixes are encrypted with the same key, since the 855 ciphertext prefixes will be identical. 857 There are OPRPs in the cryptographic literature that are suitable for 858 use in AERO, such as the Pipelineable Online Encryption (POE) mode of 859 operation [AFFFLMW14], or the McOE-G [FFLW11] family of online 860 authenticated encryption algorithms of Fleischmann, Forler, Lucks, 861 and Wenzel. 863 There are offline ciphers that are more efficient that WPRPs, such as 864 the Synthetic Initialization Vector (SIV) mode of operation of 865 Rogaway and Shrimpton [RFC5297]. SIV encryption makes two passes 866 over the plaintext, first to compute a Message Authentication Code 867 (MAC) of that plaintext, the second to encrypt the plaintext using 868 counter mode, using the MAC as the initialization vector for the 869 encryption process. This two-pass encryption approach can be adapted 870 for use in AERO, by having the IV computed by the tweakable 871 encryption of the sequence number, using the MAC as the tweak. Such 872 a mode of operation could be computationally less costly than a WPRP, 873 but would also lack some of the misuse-resistance properties of a 874 WPRP. 876 6. Loss, reorder, and resynchronization 878 AERO relies on the synchronization of the sequence number S between 879 the sender (encryption algorithm) and the receiver (decryption 880 algorithm). If those values differ by more than W, then we say that 881 the sender and receiver are desynchronized; if this occurs, then it 882 is likely that the decryption algorithm will discard at least one 883 legitimate message that it receives. Desynchronization will occur 884 whenever W+1 or more messages are lost by the communication channel 885 between the sender and the receiver. 887 When initializing an AERO decryption context, the reorder tolerance 888 parameter W should be set to a value that is larger than the message 889 reorder of the communication channel in use. However, values of W 890 larger than 256 are discouraged for security reasons; see Section 11. 891 The default value of W=64 is recommended when AERO ciphertext 892 messages are carried over an unreliable transport protocol. When 893 they are carried over a reliable transport protocol, W=1 is 894 recommended. 896 Resynchronization occurs automatically in AERO, because of the 897 processing of candidate sequence numbers between R+1 and R+V. If a 898 burst of exactly J messages that are lost, where J > W+1, then the 899 receiver will reject the first message received immediately after the 900 burst of lost messages, and will set R to the value of the current 901 sequence number S of the sender. The candidate sequence number of 902 the next message received will fall into the region between R+1 and 903 R+V, since R=S and the candidate sequence number is S+1. Thus, after 904 a burst of J > W lost packets, resynchronization is obtained after 905 the spurious rejection of a single packet. 907 Most applications can accept the induced loss of a single message in 908 situations where J > W or more messages have been lost, since this 909 corresponds to an increase in packet loss less than 2% when the 910 recommended value of W=64 is used. However, an application MAY 911 choose to cache a rejected message (A, C) and re-submit it to the 912 AERO decryption algorithm if it appears to have been spuriously 913 rejected during the resynchronization process, to eliminate the 914 induced message loss. An application can do this without any need 915 for special processing from an AERO implementation. 917 When there are multiple receivers, it may be the case that one of the 918 receivers is a "late joiner" that does not receive the initial 919 messages sent in a session, because it joined that session some time 920 after it began. The automatic resynchronization described above will 921 enable a late joiner to synchronize with the sender after a single 922 spurious rejection of a valid message. If an application protocol is 923 designed to allow a late joiner in a session, it is likely that the 924 application can tolerate this one spurious rejection as the cost of 925 achieving synchronization without external coordination of state. 927 The one free parameter in an AERO implementation is the number T of 928 bits in the sequence number. This parameter determines the strength 929 of the authentication provided, as well as the number of messages 930 that can be encrypted by a particular sender using a particular key. 931 Securty is the main consideration in the selection of this parameter; 932 this topic is covered in Section 11.1.1. 934 7. Usage and applicability 936 AERO addresses several outstanding issues in cryptography as it is 937 used for communication security. It is especially well suited for 938 scenarios where there are bandwidth constrains or high costs 939 associated with transmission and reception, as well as scenarios in 940 which multiple senders or multiple receivers share an encryption key. 941 It is also suitable for use when misuse resistance is desirable. 943 AERO always detects replayed messages, as is expected of a replay 944 protection service, but AERO may reject a message because it does not 945 have all of the stored state that it needs in able to authoritatively 946 determine that the message is not a replay. In this way, it matches 947 the conventional practice of replay protection using sequence 948 numbers. 950 The sequence number output by the decryption algorithm can be used by 951 the application calling AERO to put the decrypted plaintexts into 952 their correct order. Some applications will not need this 953 information, because they can rely on information in the associated 954 data or plaintext to get information about the ordering of messages, 955 or because they do not need to process the messages in order. 957 When AERO ciphertext messages are carried above a reliable transport 958 protocol such as TCP or SCCP, the reorder tolerance parameter W can 959 be set to one and the resynchronization parameter V can be set to 960 zero. This has the effect of improving the strength of the 961 authentication that is provided. 963 AERO-WPRP should be used, unless it is not possible to buffer the 964 entire plaintext or ciphertext in memory during the encryption and 965 decryption processes, in which case an AERO-OPRP would be more 966 appropriate. Currently, there are no OPRP algorithms that can be 967 implemented in an efficient pipeline, as is done with other AEAD 968 algorithms such as AES-GCM, so this is an area of ongoing work. 970 8. Rationale 972 AES-XCB was chosen as it provides suitable security and performance, 973 and it is a standard. In the future, stateless encryption algorithms 974 with performance or security benefits over AES-XCB may be developed, 975 but it is essential to specify a particular algorithm in this note, 976 in order to gain experience in the implementation and use of AERO. 978 It is unfortunate, but unavoidable, that the plaintext must be 979 padded. It is unfortunate because of the slight additional overhead 980 and implementation complexity. It is unavoidable because there is no 981 efficient way to encrypt fewer than b bytes of plaintext using a 982 block cipher with a b-byte block, in a way that meets the security 983 needs of AERO. Also, there are not (yet) any dedicated encryption 984 algorithms that are suitable. 986 The padding and pad-stripping operations are included in the AERO 987 encryption and decryption algorithms, respectively, because the pad- 988 stripping operation also incorporates an authentication check. This 989 arrangement simplifies the stateless encryption algorithm, and also 990 ensures that more algorithms can be used as stateless encryption 991 methods. 993 Incorporating the sequence number generation inside of AERO has the 994 advantage of putting that security-critical operation inside of the 995 cryptographic module, which often benefits from higher assurance than 996 other system components, including testing, as observed by Sections 5 997 and 6 of [IV-GEN]. 999 9. Testing 1001 In the typical case in which the underlying stateless encryption 1002 algorithm is deterministic, both AERO encryption and AERO decryption 1003 are deterministic. This makes it possible to use test cases for all 1004 of the operations supported by an AERO algorithm. 1006 10. IANA Considerations 1008 The Internet Assigned Numbers Authority (IANA) has defined the AERO 1009 algorithm registry described below. An algorithm designer MAY 1010 register an algorithm in order to facilitate its use. Additions to 1011 the AERO algorithm registry require that a specification be 1012 documented in an Internet RFC or another permanent and readily 1013 available reference, in sufficient detail that interoperability 1014 between independent implementations is possible. Each entry in the 1015 registry contains the following elements: 1017 a short name, such as "AERO_AES_128_XCB", that starts with the 1018 string "AERO", 1020 a positive number, and 1022 a reference to a specification that completely defines an AERO 1023 algorithm and provides test cases that can be used to verify the 1024 correctness of an implementation. 1026 Requests to add an entry to the registry MUST include the name and 1027 the reference. The number is assigned by IANA. These number 1028 assignments SHOULD use the smallest available positive number. 1029 Submitters SHOULD have their requests reviewed by the IRTF Crypto 1030 Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants 1031 that are unfamiliar with IANA processes should visit 1032 http://www.iana.org. 1034 The numbers between 32,768 (binary 1000000000000000) and 65,535 1035 (binary 1111111111111111) inclusive, will not be assigned by IANA, 1036 and are reserved for private use; no attempt will be made to prevent 1037 multiple sites from using the same value in different (and 1038 incompatible) ways [RFC2434]. 1040 An IANA registration of an AERO algorithm does not constitute an 1041 endorsement of that algorithm or its security. 1043 11. Security considerations 1045 There are three AERO security services: confidentiality, message 1046 authentication, and replay protection. We consider those services in 1047 that order. We use a simplistic but realistic model in which 1048 pseudorandom values are treated as random values. 1050 A more precise analysis would define the advantage that an adversary 1051 has in distinguishing the pseudorandom output of the stateless 1052 encryption algorithm from a truly random value, then quantify an 1053 attacker's advantage at forging AERO messages or distinguishing the 1054 output of the decryption algorithm from random, and then show that 1055 the attacker's advantage against AERO is negligibly small as long as 1056 the advantage against the stateless encryption algorithm is 1057 negligibly small. However, such a detailed analysis is beyond the 1058 scope of this note. 1060 Below we sketch out a formal security analysis for AERO, using the 1061 conventional definition of advantage as the absolute value of the 1062 difference between the probability that a distinguisher will have a 1063 true positive and the probability that it will have a false positive. 1064 AERO is secure in the following model, which captures the idea of a 1065 very strong adversary. The attacker is assumed to be able to 1066 adaptively choose plaintext messages (A, P) and ciphertext messages 1067 (A, C), and obtain the corresponding ciphertext and plaintext 1068 messages. 1070 Assume that there is an attack that can distinguish AERO from a 1071 randomly chosen function with the same domain and range. Then we can 1072 use this attack to build a distinguisher that can tell the underlying 1073 stateless encryption function from a truly random function, as 1074 follows. Given access to an oracle that is either the stateless 1075 encryption function with a randomly chosen secret key, or is a truly 1076 random function, we use that oracle to construct an AERO instance. 1077 We then run the AERO-distinguishing attack against that AERO 1078 instance, responding to the the queries made by the attack by 1079 constructing the appropriate AERO queries. If the attack returns a 1080 guess of "AERO", then we return a guess of "not random". Otherwise, 1081 return a guess of "random". This attack on the underlying encryption 1082 functions works with essentially the same advantage as the attack on 1083 AERO. 1085 Similarly, if there is an attack that can forge AERO messages with 1086 probability significantly greater than 1/2^T' (where T' is the 1087 effective authentication tag length defined below), then we can use 1088 that attack to build a distinguisher that can tell the underlying 1089 stateless encryption function from a truly random function, as 1090 follows. Given access to an oracle that is either the stateless 1091 encryption function with a randomly chosen secret key, or is a truly 1092 random function, we use that oracle to construct an AERO instance. 1093 We then run the forgery attack against that AERO instance, responding 1094 to the queries made by the attack by constructing the appropriate 1095 AERO queries. If the attack against AERO succeeds in making a 1096 forgery, then we return a guess of "not random". Otherwise, return a 1097 guess of "random". This distinguishing attack works with advantage P 1098 - 1/2^T', where P is the probability that the AERO-forgery attack 1099 will succeed in a forgery attempt. 1101 AERO is a stateful authenticated encryption method. Bellare, Kohno, 1102 and Namprempre have studied the security of stateful encrption and 1103 decryption in the context of the Secure Shell (SSH) protocol [BKN04]. 1105 11.1. Authentication and confidentiality 1107 The confidentiality properties of AERO follow directly from that of 1108 the stateless encryption algorithm that it incorporates. When a WPRP 1109 is used, each WPRP plaintext will be distinct, because of the 1110 uniqueness of the sequence numbers. This fact ensures the 1111 indistinguishability of AERO encryption from a random function, and 1112 thus the strength of the confidentiality that it provides. 1114 AERO decryption can detect forgery attempts in two ways: the 1115 processing of the candidate sequence number, and the strip function 1116 that removes padding from the plaintext. The candidate sequence 1117 number is a pseudorandom function of both the AERO ciphertext and the 1118 AERO associated data, as is the post-decryption padding string PS. 1119 To an attacker that cannot distinguish the pseudorandom value from a 1120 random one, the probability p that a forgery attempt will not be 1121 detected by the candidate sequence number processing is 1123 (2*W + V) 1124 p = ------------. 1125 2^T 1127 To an attacker that cannot distinguish the post-decryption value of 1128 PS from a random string, the probability ps that a forgery attempt 1129 will pass through the "strip" function undetected is 1131 (PMIN - T/8) 1132 ps = -------------. 1133 256 1135 Thus, the probability that a forgery attempt will go undetected is 1136 1/2^T', where 1137 T' = T + 8 - lg((2*W + V) - lg(PMIN - T/8)) 1139 and lg(X) denotes the logarithm base two of X. As revealed by the 1140 equation above, AERO provides integrity and authentication protection 1141 that is essentially equivalent to an ideal message authentication 1142 code with a tag length of T' which is slightly less than T. The 1143 following table shows T' as a function of T, using the default values 1144 of W=64 and V=8 with PMIN=16, to three significant figures. The 1145 third column shows the number of bits in the data "on the wire" 1146 required by AERO. The final column shows the delta between the 1147 number of bits on the wire and the equivalent tag size T'. 1149 +-----+------+-----------+-------+ 1150 | T | T' | Data size | Delta | 1151 +-----+------+-----------+-------+ 1152 | 128 | 121 | 128 | 7.0 | 1153 | | | | | 1154 | 120 | 121 | 128 | 7.0 | 1155 | | | | | 1156 | 112 | 112 | 120 | 8.0 | 1157 | | | | | 1158 | 104 | 103 | 112 | 9.0 | 1159 | | | | | 1160 | 96 | 94.9 | 104 | 9.1 | 1161 | | | | | 1162 | 88 | 86.6 | 96 | 9.4 | 1163 | | | | | 1164 | 72 | 70.1 | 80 | 9.9 | 1165 | | | | | 1166 | 64 | 61.9 | 72 | 10.1 | 1167 | | | | | 1168 | 56 | 53.7 | 64 | 10.3 | 1169 | | | | | 1170 | 48 | 45.6 | 56 | 10.4 | 1171 | | | | | 1172 | 40 | 37.5 | 48 | 10.5 | 1173 | | | | | 1174 | 32 | 29.3 | 40 | 10.7 | 1175 | | | | | 1176 | 28 | 25.3 | 32 | 6.7 | 1177 +-----+------+-----------+-------+ 1179 The delta values can be considered to be the data overhead inherent 1180 in AERO, that is, the amount of additional data that must be included 1181 in a message in order to provide the replay protection, sequencing 1182 information, and self-synchronization capability. For higher 1183 authentication strengths, this overhead is roughly one byte; 1184 otherwise, it is slightly higher. 1186 When AERO is used over a reliable transport protocol, then the 1187 reorder tolerance parameter W SHOULD be set to one, and the 1188 resynchronization parameter V SHOULD be set to zero. When this is 1189 done, the delta values are about 7 bits smaller, and for a given 1190 amount of data overhead, the probability of a successful forgery is 1191 smaller by a factor of about 1/128. 1193 11.1.1. Authentication strength 1195 As always, stronger authentication, and thus larger values of T', 1196 should be preferred over weaker authentication, and smaller values 1197 of T'. We recommend the use of T' = 121 (with 128 bits on the wire) 1198 whenever possible. When bandwidth is at a premium, it may be 1199 acceptable to use T' = 53.7 (64 bits on the wire). 1201 When the plaintext is audio or video data to be converted to an 1202 analog signal and played out of an audio speaker or video monitor, it 1203 may be acceptable to use even weaker authentication, whenever the 1204 consequences of a single forgery are limited to a localized "glitch" 1205 in the audio or video output. In such cases, an authentication 1206 strength of T' = 25.3 (32 bits on the wire) may be acceptable, but 1207 users are cautioned to verify these criteria before using such weak 1208 authentication. With these parameters, the likelihood of a 1209 successful forgery is one in 32 million. 1211 11.2. Length hiding 1213 In some applications, it is desirable to hide the length of the 1214 plaintext from an attacker, in order to prevent the attacker from 1215 being able to make inferences about the plaintext based on those 1216 lengths. The plaintext padding scheme defined in this note is not 1217 suitable for this purpose and it MUST NOT be used as such. An 1218 application that seeks to hide plaintext lengths should instead 1219 process the plaintexts with a fragmentation and encoding scheme prior 1220 to encrypting them. Schemes of this sort are out of scope of this 1221 note. 1223 11.3. Denial of Service (DoS) 1225 An attacker can potentially flood a communications channel with a set 1226 of bogus ciphertext messages in order to consume the computational 1227 resources of the receiver. In this section we review the 1228 vulnerability of AERO to this type of attack. 1230 AERO synchronization is robust even in the face of a DoS attack. An 1231 AERO sender and receiver will stay in synchronization unless either 1232 1) the attacker succeeds in forging a message, or 2) a burst of at 1233 least B messages have been lost. The forgery likelihood is 1234 determined by the parameters T, V, and W, and it can be set high 1235 enough that the attacker's chance of success is negligible. A DoS 1236 attack may cause bursts of lost messages, by causing congestion on 1237 communication links. But AERO recovers quickly once that loss is 1238 over. 1240 AERO requires that all of the cryptographic processing be done during 1241 the decryption algorithm in order to detect a forgery attempt. This 1242 is in contrast to other authenticated encryption algorithms (e.g. 1243 GCM) that can avoid doing decryption processing, since the 1244 authentication check can be completed before the encryption starts. 1245 When AERO is in use on a communication environment where the data 1246 rate of the communications greatly exceeds that of AERO decryption, 1247 it may be beneficial to use additional mechanisms that allow the 1248 receiver to reject bogus messages. This could include having a 1249 fixed, unpredictable value in each message in order to foil off-path 1250 DoS attacks. To defend against on-path attackers, cryptographic 1251 techniques can be used. These techniques are beyond the scope of 1252 this document. 1254 11.4. Multiple senders 1256 Section 3.5 describes the sender uniqueness requirement: a set of 1257 senders sharing the same key are recommended to ensure that their 1258 associated data inputs to the encryption algorithm will be distinct, 1259 for instance by including information in the associated data that 1260 uniquely identifies each sender. If the senders do not meet this 1261 requirement, then the security will degrade somewhat. The details of 1262 this degradation depend on the details of the underlying encryption 1263 method. 1265 When a WPRP is used in AERO and the sender uniqueness requirement is 1266 not met, an attacker can recognize when the same exact plaintext 1267 message (A, P) is encrypted by different senders with the same 1268 sequence number. Symbolically, if sender S1 and sender S2 both use 1269 the same associated data value A and plaintext value P in the ith 1270 message in sequence that they are each independently encrypting, then 1271 the resulting ciphertexts will be identical, and an attacker can 1272 infer that the plaintexts are matching. In many real-world 1273 scenarios, it is highly unlikely that distinct senders will each 1274 encrypt the same plaintext value for the same sequence number, and 1275 thus the security degradation will be tolerable. If, however, the 1276 plaintexts are either very short (such as eight or fewer octets) or 1277 very repetitive (there are only a million possible plaintexts, for 1278 instance), then the loss of confidentiality may be unacceptably high. 1280 When the sender uniqueness requirement is not met, the receiver will 1281 be processing messages from two or more senders, while believing it 1282 to be from a single sender. The decryption algorithm will 1283 synchronize with the highest sequence number of any sender, and 1284 reject the messages from other senders, if the highest sequence 1285 number is at least W greater than all other sequence numbers. If the 1286 sequence numbers of the senders are close, then the receiver will 1287 interleave messages from different senders. In the latter case, an 1288 attacker could potentially manipulate what the post-decryption 1289 plaintext looks like by selectively withholding messages from 1290 particular senders. Note that this property is not particular to 1291 AERO; it holds for any authenticated encryption scheme in which 1292 multiple entities are sharing the encryption key, and the receiver 1293 has no way of determining which entity encrypted a particular 1294 ciphertext message. 1296 These security properties compare very favorably with those of 1297 conventional authenticated encryption schemes. When the sender 1298 uniqueness requirement is not met with a nonce-based encryption 1299 scheme such as counter mode, CCM, GCM, Salsa or ChaCha, then 1300 essentially all of the confidentiality guarantees are lost. For 1301 nonce-based authentication schemes such as GCM, GMAC, and UMAC, all 1302 of the authentication guarantees are lost. 1304 11.5. Sequence number management failure 1306 An AERO implementation might accidentally mismanage sequence numbers, 1307 due to faulty logic in the implementation, or due to external factors 1308 such as the cloning of the state of the virtual machine on which the 1309 implementation is running. If this happens, security will degrade. 1310 In order to ensure that the degradation is not catastrophic, the 1311 underlying stateless encryption algorithm should be robust against 1312 nonce misuse, in the sense of [RFC5297]. 1314 12. Acknowledgements 1316 The authors thank Dan Wing, Stefan Lucks, and Brian Weis for feedback 1317 and discussions, and Richard Barnes, Kenny Paterson, and Robert 1318 Moskowitz for suggestions and corrections. 1320 13. References 1322 13.1. Normative references 1324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1325 Requirement Levels", BCP 14, RFC 2119, March 1997. 1327 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1328 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1329 October 1998. 1331 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1332 Encryption", RFC 5116, January 2008. 1334 13.2. Informative references 1336 [1619.2] "IEEE 1619.2-2010: Standard for Wide-Block Encryption for 1337 Shared Storage Media", IEEE Computer Society https:// 1338 standards.ieee.org/findstds/standard/1619.2-2010.html, 1339 2010. 1341 [AFFFLMW14] 1342 Abed, Fluhrer, Foley, Forler, Lucks, McGrew, and Wenzel, 1343 "Pipelineable Online Encryption", Proceedings of the 21st 1344 international conference on Fast Software Encryption (FSE 1345 2014) . 1347 [BKN04] Bellare, Kohno, and Namprempre, "Breaking and provably 1348 repairing the SSH authenticated encryption scheme: A case 1349 study of the Encode-then-Encrypt-and-MAC paradigm", ACM 1350 Transactions on Information and System Security, 7(2), May 1351 2004. http://homes.cs.washington.edu/~yoshi/papers/SSH/. 1353 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1354 Relations among notions and analysis of the generic 1355 composition paradigm", Proceedings of ASIACRYPT 2000, 1356 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1357 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1359 [CCM] Dworkin, "NIST Special Publication 800-38C: The CCM Mode 1360 for Authentication and Confidentiality", U.S. National 1361 Institute of Standards and Technology http:// 1362 csrc.nist.gov/publications/nistpubs/SP800-38C.pdf. 1364 [CS07] Chakraborty, D. and P. Sarkar, "HCH: A New Tweakable 1365 Enciphering Scheme Using the Hash-Counter-Hash Approach", 1366 IACR eprint archive http://eprint.iacr.org/2007/28, 2007. 1368 [FFLW11] Fleischmann, Forler, Lucks, and Wenzel, "McOE: a family of 1369 almost foolproof on-line authenticated encryption 1370 schemes", Proceedings of the 19th international conference 1371 on Fast Software Encryption (FSE 2011) . 1373 [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal 1374 Information Processing Standard 1375 (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. 1377 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 1378 Operation (GCM)", Submission to NIST http://csrc.nist.gov/ 1379 CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf, 1380 January 2004. 1382 [IV-GEN] McGrew, D., "Generation of Deterministic Initialization 1383 Vectors (IVs) and Nonces", IETF Internet 1384 Draft http://www.ietf.org/id/draft-mcgrew-iv-gen-03.txt, 1385 October 2013. 1387 [MF07] McGrew, D. and S. Fluhrer, "The Security of the Extended 1388 Codebook (XCB) Mode of Operation", 14th Workshop on 1389 Selected Areas in Cryptography (SAC 1390 2007) http://eprint.iacr.org/2007/298, August 2007. 1392 [R02] Rogaway, P., "Authenticated encryption with Associated- 1393 Data", Proceedings of the 2002 ACM Conference on Computer 1394 and Communication Security (CCS'02), pp. 98-107, ACM 1395 Press, 1396 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. 1398 [RFC4418] Krovetz, T., "UMAC: Message Authentication Code using 1399 Universal Hashing", RFC 4418, March 2006. 1401 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1402 Transform Carrying Roll-Over Counter for the Secure Real- 1403 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1405 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1406 Authenticated Encryption Using the Advanced Encryption 1407 Standard (AES)", RFC 5297, October 2008. 1409 [S07] Sarkar, P., "Improving Upon the TET Mode of Operation", 1410 IACR eprint archive http://eprint.iacr.org/2007/317, 1411 2007. 1413 [SP800-38] 1414 Dworkin, M., "NIST Special Publication 800-38: 1415 Recommendation for Block Cipher Modes of Operation", U.S. 1417 National Institue of Standards and Technology http:// 1418 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 1420 Authors' Addresses 1422 David McGrew 1423 Cisco Systems 1424 13600 Dulles Technology Drive 1425 Herndon, VA 20171 1426 US 1428 Email: mcgrew@cisco.com 1429 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1431 John Foley 1432 Cisco Systems 1433 7025-2 Kit Creek Road 1434 Research Triangle Park, NC 14987 1435 US 1437 Email: foleyj@cisco.com