idnits 2.17.1 draft-josefsson-ssh-chacha20-poly1305-openssh-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '...been received, the MAC MUST be checked...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 26, 2015) is 3066 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Miller 3 Internet-Draft OpenSSH 4 Intended status: Informational S. Josefsson 5 Expires: May 29, 2016 SJD AB 6 November 26, 2015 8 The chacha20-poly1305@openssh.com authenticated encryption cipher 9 draft-josefsson-ssh-chacha20-poly1305-openssh-00 11 Abstract 13 This document describes the chacha20-poly1305@openssh.com 14 authenticated encryption cipher supported by OpenSSH 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 29, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Detailed Construction . . . . . . . . . . . . . . . . . . . . 2 53 4. Packet Handling . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 58 7.2. Informative References . . . . . . . . . . . . . . . . . 4 59 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 ChaCha20 is a stream cipher designed by Daniel Bernstein and 65 described in [ChaCha]. It operates by permuting 128 fixed bits, 128 66 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes 67 of output. This output is used as a keystream, with any unused bytes 68 simply discarded. 70 Poly1305 [Poly1305], also by Daniel Bernstein, is a one-time Carter- 71 Wegman MAC that computes a 128 bit integrity tag given a message and 72 a single-use 256 bit secret key. 74 The "chacha20-poly1305@openssh.com" combines these two primitives 75 into an authenticated encryption mode. The construction used is 76 based on that proposed for TLS by Adam Langley in 77 [I-D.agl-tls-chacha20poly1305], but differs in the layout of data 78 passed to the MAC and in the addition of encyption of the packet 79 lengths. 81 2. Negotiation 83 The chacha20-poly1305@openssh.com offers both encryption and 84 authentication. As such, no separate MAC is required. If the 85 chacha20-poly1305@openssh.com cipher is selected in key exchange, the 86 offered MAC algorithms are ignored and no MAC is required to be 87 negotiated. 89 3. Detailed Construction 91 The chacha20-poly1305@openssh.com cipher requires 512 bits of key 92 material as output from the SSH key exchange. This forms two 256 bit 93 keys (K_1 and K_2), used by two separate instances of chacha20. 95 The instance keyed by K_1 is a stream cipher that is used only to 96 encrypt the 4 byte packet length field. The second instance, keyed 97 by K_2, is used in conjunction with poly1305 to build an AEAD 98 (Authenticated Encryption with Associated Data) that is used to 99 encrypt and authenticate the entire packet. 101 Two separate cipher instances are used here so as to keep the packet 102 lengths confidential but not create an oracle for the packet payload 103 cipher by decrypting and using the packet length prior to checking 104 the MAC. By using an independently-keyed cipher instance to encrypt 105 the length, an active attacker seeking to exploit the packet input 106 handling as a decryption oracle can learn nothing about the payload 107 contents or its MAC (assuming key derivation, ChaCha20 and Poly1305 108 are secure). 110 The AEAD is constructed as follows: for each packet, generate a 111 Poly1305 key by taking the first 256 bits of ChaCha20 stream output 112 generated using K_2, an IV consisting of the packet sequence number 113 encoded as an uint64 under the SSH wire encoding rules and a ChaCha20 114 block counter of zero. The K_2 ChaCha20 block counter is then set to 115 the little-endian encoding of 1 (i.e. {1, 0, 0, 0, 0, 0, 0, 0}) and 116 this instance is used for encryption of the packet payload. 118 4. Packet Handling 120 When receiving a packet, the length must be decrypted first. When 4 121 bytes of ciphertext length have been received, they may be decrypted 122 using the K_1 key, a nonce consisting of the packet sequence number 123 encoded as a uint64 under the usual SSH wire encoding and a zero 124 block counter to obtain the plaintext length. 126 Once the entire packet has been received, the MAC MUST be checked 127 before decryption. A per-packet Poly1305 key is generated as 128 described above and the MAC tag calculated using Poly1305 with this 129 key over the ciphertext of the packet length and the payload 130 together. The calculated MAC is then compared in constant time with 131 the one appended to the packet and the packet decrypted using 132 ChaCha20 as described above (with K_2, the packet sequence number as 133 nonce and a starting block counter of 1). 135 To send a packet, first encode the 4 byte length and encrypt it using 136 K_1. Encrypt the packet payload (using K_2) and append it to the 137 encrypted length. Finally, calculate a MAC tag and append it. 139 5. Rekeying 141 ChaCha20 must never reuse a {key, nonce} for encryption nor may it be 142 used to encrypt more than 2^70 bytes under the same {key, nonce}. The 143 SSH Transport protocol [RFC4253] recommends a far more conservative 144 rekeying every 1GB of data sent or received. If this recommendation 145 is followed, then chacha20-poly1305@openssh.com requires no special 146 handling in this area. 148 6. Acknowledgements 150 Markus Friedl helped on the design. 152 7. References 154 7.1. Normative References 156 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 157 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 158 January 2006, . 160 [ChaCha] Bernstein, J., "ChaCha, a variant of Salsa20", January 161 2008, . 163 [Poly1305] 164 Bernstein, J., "The Poly1305-AES message-authentication 165 code", March 2005, 166 . 168 7.2. Informative References 170 [I-D.agl-tls-chacha20poly1305] 171 Langley, A. and W. Chang, "ChaCha20 and Poly1305 based 172 Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 173 (work in progress), November 2013. 175 Appendix A. Copying conditions 177 Regarding this entire document or any portion of it, the authors make 178 no guarantees and are not responsible for any damage resulting from 179 its use. The authors grant irrevocable permission to anyone to use, 180 modify, and distribute it in any way that does not diminish the 181 rights of anyone else to use, modify, and distribute it, provided 182 that redistributed derivative works do not contain misleading author 183 or version information. Derivative works need not be licensed under 184 similar terms. 186 Authors' Addresses 188 Damien Miller 189 OpenSSH 191 Simon Josefsson 192 SJD AB 194 Email: simon@josefsson.org