The [email protected] authenticated encryption cipher (2024)

Network Working Group D. MillerInternet-Draft OpenSSHIntended status: Informational S. JosefssonExpires: May 29, 2016 SJD AB November 26, 2015 The [email protected] authenticated encryption cipher draft-josefsson-ssh-chacha20-poly1305-openssh-00Abstract This document describes the [email protected] authenticated encryption cipher supported by OpenSSHStatus of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 29, 2016.Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Miller & Josefsson Expires May 29, 2016 [Page 1]

Internet-Draft SSH [email protected] November 2015Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Detailed Construction . . . . . . . . . . . . . . . . . . . . 2 4. Packet Handling . . . . . . . . . . . . . . . . . . . . . . . 3 5. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51. Introduction ChaCha20 is a stream cipher designed by Daniel Bernstein and described in [ChaCha]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded. Poly1305 [Poly1305], also by Daniel Bernstein, is a one-time Carter- Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key. The "[email protected]" combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley in [I-D.agl-tls-chacha20poly1305], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths.2. Negotiation The [email protected] offers both encryption and authentication. As such, no separate MAC is required. If the [email protected] cipher is selected in key exchange, the offered MAC algorithms are ignored and no MAC is required to be negotiated.3. Detailed Construction The [email protected] cipher requires 512 bits of key material as output from the SSH key exchange. This forms two 256 bit keys (K_1 and K_2), used by two separate instances of chacha20.Miller & Josefsson Expires May 29, 2016 [Page 2]

Internet-Draft SSH [email protected] November 2015 The instance keyed by K_1 is a stream cipher that is used only to encrypt the 4 byte packet length field. The second instance, keyed by K_2, is used in conjunction with poly1305 to build an AEAD (Authenticated Encryption with Associated Data) that is used to encrypt and authenticate the entire packet. Two separate cipher instances are used here so as to keep the packet lengths confidential but not create an oracle for the packet payload cipher by decrypting and using the packet length prior to checking the MAC. By using an independently-keyed cipher instance to encrypt the length, an active attacker seeking to exploit the packet input handling as a decryption oracle can learn nothing about the payload contents or its MAC (assuming key derivation, ChaCha20 and Poly1305 are secure). The AEAD is constructed as follows: for each packet, generate a Poly1305 key by taking the first 256 bits of ChaCha20 stream output generated using K_2, an IV consisting of the packet sequence number encoded as an uint64 under the SSH wire encoding rules and a ChaCha20 block counter of zero. The K_2 ChaCha20 block counter is then set to the little-endian encoding of 1 (i.e. {1, 0, 0, 0, 0, 0, 0, 0}) and this instance is used for encryption of the packet payload.4. Packet Handling When receiving a packet, the length must be decrypted first. When 4 bytes of ciphertext length have been received, they may be decrypted using the K_1 key, a nonce consisting of the packet sequence number encoded as a uint64 under the usual SSH wire encoding and a zero block counter to obtain the plaintext length. Once the entire packet has been received, the MAC MUST be checked before decryption. A per-packet Poly1305 key is generated as described above and the MAC tag calculated using Poly1305 with this key over the ciphertext of the packet length and the payload together. The calculated MAC is then compared in constant time with the one appended to the packet and the packet decrypted using ChaCha20 as described above (with K_2, the packet sequence number as nonce and a starting block counter of 1). To send a packet, first encode the 4 byte length and encrypt it using K_1. Encrypt the packet payload (using K_2) and append it to the encrypted length. Finally, calculate a MAC tag and append it.Miller & Josefsson Expires May 29, 2016 [Page 3]

Internet-Draft SSH [email protected] November 20155. Rekeying ChaCha20 must never reuse a {key, nonce} for encryption nor may it be used to encrypt more than 2^70 bytes under the same {key, nonce}. The SSH Transport protocol [RFC4253] recommends a far more conservative rekeying every 1GB of data sent or received. If this recommendation is followed, then [email protected] requires no special handling in this area.6. Acknowledgements Markus Friedl helped on the design.7. References7.1. Normative References [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <http://www.rfc-editor.org/info/rfc4253>. [ChaCha] Bernstein, J., "ChaCha, a variant of Salsa20", January 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>. [Poly1305] Bernstein, J., "The Poly1305-AES message-authentication code", March 2005, <http://cr.yp.to/mac/poly1305-20050329.pdf>.7.2. Informative References [I-D.agl-tls-chacha20poly1305] Langley, A. and W. Chang, "ChaCha20 and Poly1305 based Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 (work in progress), November 2013.Appendix A. Copying conditions Regarding this entire document or any portion of it, the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.Miller & Josefsson Expires May 29, 2016 [Page 4]

Internet-Draft SSH [email protected] November 2015Authors' Addresses Damien Miller OpenSSH Simon Josefsson SJD AB Email: [email protected] & Josefsson Expires May 29, 2016 [Page 5]