idnits 2.17.1 draft-moskowitz-small-crypto-00.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2017) is 2362 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '144' on line 175 -- Looks like a reference, but probably isn't: '256' on line 175 == Missing Reference: 'FIPS 202' is mentioned on line 175, but not defined == Missing Reference: 'SP 800-185' is mentioned on line 177, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CURDLE R. Moskowitz 3 Internet-Draft L. Xia 4 Intended status: Informational Huawei 5 Expires: May 3, 2018 October 30, 2017 7 Small Crypto for Small IOT 8 draft-moskowitz-small-crypto-00 10 Abstract 12 This memo proposes to leverage the Keccak algorithm at a function 13 "width" of b=400 to provide a set of "small" cryptographic functions 14 well suited to the IOT constrained environment. As such, only 128 15 bit security level is provided here. The full set of NIST approved 16 Keccak derived functions that can work within the b=400 constraint, 17 plus the 3rd round candidate in the CAESAR competition, Ketje, are 18 defined. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 3, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Document status . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Keccak Basics . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Keccak Parameters . . . . . . . . . . . . . . . . . . . . 4 62 4. Keccak[144,256] . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. The Ketje authenticated encryption scheme . . . . . . . . . . 5 64 6. Using SHAKE128i in Ed25519 . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 8.1. Defense against future attacks . . . . . . . . . . . . . 5 68 8.2. Security Comparisons . . . . . . . . . . . . . . . . . . 5 69 8.2.1. SHAKE128i to SHA-256 . . . . . . . . . . . . . . . . 5 70 8.2.2. KMAC128i to HMAC(SHA-256) . . . . . . . . . . . . . . 5 71 8.2.3. Ketje Sr to AES-CCM . . . . . . . . . . . . . . . . . 5 72 8.2.4. Ed25519i to Ed25519 . . . . . . . . . . . . . . . . . 6 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 10.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 7 78 A.1. Pacemaker connected via Body Area Network . . . . . . . . 7 79 A.2. Automotive CAN FD Sensors . . . . . . . . . . . . . . . . 7 80 A.3. Building Automation and Control Network Sensors . . . . . 8 81 Appendix B. Performance Comparisons . . . . . . . . . . . . . . 8 82 B.1. SHAKE128i to SHA-256 . . . . . . . . . . . . . . . . . . 8 83 B.2. KMAC128i to HMAC(SHA-256) . . . . . . . . . . . . . . . . 8 84 B.3. Ketje Sr to AES-CCM . . . . . . . . . . . . . . . . . . . 8 85 B.4. Ed25519i to Ed25519 . . . . . . . . . . . . . . . . . . . 8 86 B.5. Keccak Hardware to AES Hardware . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction 91 The Keccak [Keccak] algorithm at a width of b=1600 was selected by 92 NIST for SHA-3 as defined in FIPS 202 [NIST.FIPS.202]. It is further 93 used to define additional hashing functions in NIST SP 800-185 94 [NIST.SP.800_185], all with b=1600. This selection is well suited 95 for 64 bit processors and large messages. It can take advantage of 96 multiple core CPUs and works well even on 32 bit processors. It is 97 not well suited for small messages and 8 bit processors that are 98 common in IOT. 100 A full set of function widths of 25, 50, 100, 200, 400, and 800 are 101 also defined in Keccak. Selection of values of other than 1600 is a 102 risk/design trade off. A width of 400 is used here as the smallest 103 that can provide 128 bits security strength. 105 Keccak provides more than a secure hash function. FIPS 202 defines 106 the SHAKE function to provide a hash output of arbitrary length, 107 rather than current practice of truncating a longer hash to the 108 needed length. SP 800-185 defines a keyed hash, KMAC, that does not 109 require the HMAC complexity and computational cost. This also can 110 provide a PRF. 112 Finally, Keccak also provides an AEAD cipher, Ketje, to thus deliver 113 in a single base function, the full suite of symmetric cryptographic 114 functions. 116 1.1. Document status 118 Significant portions of this document are stubs. That is not because 119 the information is not available. Rather the information for those 120 sections need to be formatted for inclusion in this document. All 121 the algorithms exist for Keccak and need only be adjusted for B=400. 122 There is considerable performance data and security comparison data 123 from the Keccak team. It needs extraction from other publications 124 and formatted into this document. 126 2. Terms and Definitions 128 2.1. Requirements Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 2.2. Notations 136 This section will contain notations 138 2.3. Definitions 140 TBD 142 3. Keccak Basics 144 Keccak is a extendable-output function (XOF) sponge construction 145 hash. It breaks from the 'standard' ARX (addition, rotation and 146 exclusive-or (XOR)) hash approach. Instead it using only bit-level 147 transpositions, bit-level additions and multiplications (in GF(2)). 148 This contributes to its superior performance. 150 This leads to one important nomenclature difference in Keccak. It 151 does not have a block size. Rather in Keccak there is bit-rate which 152 is one of the variable parameters. 154 3.1. Keccak Parameters 156 The Keccak primitive is: 158 Keccak-f[b], where b is 25, 50, 100, 200, 400, 800 or 1600 bits 160 b=1600 is used in FIPS 202 and SP 800-185. Here, b=400 is used. 162 Instances are denoted 164 Keccak[r, c] 166 capacity c determines the proven security strength against 167 generic attacks 168 for a security level of n bits, the capacity must be c = 2n 169 and bitrate r = b - c 171 Thus for b=400 and a strength of 128 bits, r=144 and c=256 173 4. Keccak[144,256] 175 The instance Keccak[144,256] can be used for SHAKE128 [FIPS 202], 176 cSHAKE128, KMAC128, KMACXOF128, TupleHash128, TupleHashXOF128, 177 ParallelHash128, ParallelHashXOF128 [SP 800-185]. The difference is 178 a bitrate of 144 rather than 1344. 180 Some of the above variants, such as the parallel hashes are not of 181 value in small devices with small r which is not amendable to tree 182 hashing. 184 To distinguish the form of the above hashes between the standard 185 r=1344 and r=144, a designation of 'i' is appended to each name so 186 that here SHAKE128i and KMAC128i are used. 188 5. The Ketje authenticated encryption scheme 190 Ketje Sr [Ketje] is already defined to use b=400. 192 6. Using SHAKE128i in Ed25519 194 Ed25519, RFC 8032 [RFC8032], specifies the parameter H(x) as SHA-512. 195 A new form, Ed25519i, will use SHAKE128i for H(x). This one change 196 will bring Ed25519 more into the 'reach' of the constrained 197 environment. 199 The use of SHAKE128i is the only variant between Ed25519 and 200 Ed25519i. 202 7. IANA Considerations 204 TBD. OID assignments 206 8. Security Considerations 208 8.1. Defense against future attacks 210 The safety margin in Keccak can be increased or de-creased simply by 211 changing the number of rounds in Keccak-f. This is explained in 212 "Note on Keccak parameters and usage" [NotesPandU], Section 6. 214 8.2. Security Comparisons 216 This memo proposes a radical change in the basic cryto-primatives 217 used in protocols. As such, care is called for. 219 Keccak is not new. It has been well reviewed as explained in "Why 220 Keccak is not ARX" [notARX]. Still, it is important to compare each 221 Keccak function proposed here against the current Best Practice. 223 8.2.1. SHAKE128i to SHA-256 225 TBD. 227 8.2.2. KMAC128i to HMAC(SHA-256) 229 TBD. 231 8.2.3. Ketje Sr to AES-CCM 233 TBD. 235 8.2.4. Ed25519i to Ed25519 237 TBD. 239 9. Acknowledgments 241 Sections here draw heavily on information available on the Keccak 242 [Keccak] site. I thank the Keccak Team in making this information 243 openly available. 245 10. References 247 10.1. Normative References 249 [NIST.FIPS.202] 250 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 251 Extendable-Output Functions", FIPS PUB 202, 252 DOI 10.6028/nist.fips.202, August 2015, 253 . 255 [NIST.SP.800_185] 256 Kelsey, J., Change, S., and R. Perlner, "SHA-3 Derived 257 Functions: cSHAKE, KMAC, TupleHash and ParallelHash", 258 Special Publication SP 800-185, 259 DOI 10.6028/nist.sp.800-185, December 2016, 260 . 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, . 268 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 269 Signature Algorithm (EdDSA)", RFC 8032, 270 DOI 10.17487/RFC8032, January 2017, . 273 10.2. Informative References 275 [IEEE.802.15.6_2012] 276 IEEE, "IEEE Standard for Local and metropolitan area 277 networks - Part 15.6: Wireless Body Area Networks", 278 IEEE 802.15.6-2012, DOI 10.1109/ieeestd.2012.6161600, 279 February 2012, . 282 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 283 R. Van Keer, "Team Keccak Home Page", 284 . 286 [Ketje] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 287 R. Van Keer, "The Ketje authenticated encryption scheme", 288 . 290 [notARX] "Why Keccak is not ARX", . 293 [NotesPandU] 294 Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, 295 "Note on Keccak parameters and usage", February 2010, 296 . 299 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 300 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 301 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 302 May 2017, . 304 Appendix A. Use Cases 306 TBD. 308 A.1. Pacemaker connected via Body Area Network 310 In-body sensors, like pacemakers, connected via the Body Area Network 311 (BAN [IEEE.802.15.6_2012]) will be very power conscious. Battery 312 replacement can often require surgery. This will lead to loose 313 interpretation of the HIPAA protection requirements to the detriment 314 of the patient. In-body sensors are an important class of devices 315 that would benefit from the most power and code efficient security 316 components that still meet a strong security claim. 318 A.2. Automotive CAN FD Sensors 320 CAN FD (CAN with Flexible Data-Rate) is an extension to the original 321 CAN bus protocol specified in ISO 11898-1. Developed in 2011 and 322 released in 2012. Its larger data payload of 64 bytes can support a 323 encrypting and authenticating protocol, but various in-vehicle 324 constraints can make this challenging. Sensors may be in a very high 325 temperature environment, making even a marginal CPU temperature 326 increase due to heavy computations catastrophic. Cost is always a 327 automotive component constraint and security tends to come in last in 328 the cost competition. Thus any way that the cost of security can be 329 lowered is a major win. 331 A.3. Building Automation and Control Network Sensors 333 BACnet (ISO 16484-5) is the standard for wired, in-building control 334 systems. Recently IPv6 support (RFC 8163 [RFC8163]) was added. Some 335 BACnet devices are extremely constrained; 4-bit processors are still 336 common. Though AES on such 4-bit processors is available, it is 337 extremely slow. A smaller security suite would be a real benefit for 338 this environment. 340 Appendix B. Performance Comparisons 342 Most new crypto algorithm changes are to reduce risk. This proposal 343 is to reduce cost and thus enable security in a lower class of 344 devices as currently supported. This will only come about if there 345 is a real performance improvement to justify potential non- 346 interoperability. 348 Performance improvements can come for lower CPU/power demands, 349 smaller code size, and/or smaller storage/memory requirements. 351 B.1. SHAKE128i to SHA-256 353 TBD. Magnitude faster? 355 B.2. KMAC128i to HMAC(SHA-256) 357 TBD. 359 B.3. Ketje Sr to AES-CCM 361 TBD. 363 B.4. Ed25519i to Ed25519 365 TBD. 367 B.5. Keccak Hardware to AES Hardware 369 TBD. 371 Authors' Addresses 373 Robert Moskowitz 374 Huawei 375 Oak Park, MI 48237 377 Email: rgm@labs.htt-consult.com 378 Liang Xia 379 Huawei 380 No. 101, Software Avenue, Yuhuatai District 381 Nanjing 382 China 384 Email: Frank.xialiang@huawei.com