The chacha20-poly1305 authenticated encryption cipher
draft-josefsson-ssh-chacha20-poly1305-openssh-00

Abstract

This document describes the chacha20-poly1305 authenticated encryption cipher for use in SSH based on AEAD_CHACHA20_POLY1305 described in [RFC7539].

Status 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 November 3, 2016.

Copyright Notice

Copyright (c) 2016 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.

Table of Contents

• 1. Introduction
• 2. Negotiation
• 3. Detailed Construction
• 3.1. Additional Authenticated Data
• 4. Packet Handling
• 4.1. Padding
• 4.2. Receiving packets
• 4.3. Sending packets
• 5. Rekeying
• 6. Differences to "chacha20-poly1305@openssh.com"
• 7. Security considerations
• 8. IANA considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A. Copying conditions
• Authors' Addresses

1. Introduction

AEAD_CHACHA20_POLY1305 from [RFC7539] is an "Authenticated Encryption with Associated Data" (AEAD) cipher. It takes a 256-bit key and a 96-bit nonce, and is based on the ChaCha20 and Poly1305 primitives both designed by Daniel Bernstein.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Negotiation

The chacha20-poly1305 encryption algorithm offers both encryption and authentication. As such, no separate MAC is required. If the chacha20-poly1305 algorithm is selected in key exchange, the offered MAC algorithms MUST be ignored and no MAC is required to be present.

3. Detailed Construction

The chacha20-poly1305 cipher requires 256 bits (32 bytes) of key material as output from the SSH key exchange.

chacha20-poly1305 does not require any "Initial IV" or "Integrity" key material.

The nonce is constructed by appending the big-endian encoding of the 32-bit sequence number to 8 zero bytes.

Section 2.6 in [RFC7539] describes how the Poly1305 key is generated from the output of the first (counter = 0) ChaCha20 block for a given packet. The second half of this block ("The other 256 bits") are discarded usually. The next 32 bits of those otherwise discarded 256 bits are used as packet_length_encryption.

The packet_length is encrypted by performing XOR of the packet_length with the packet_length_encryption.

The chacha20-poly1305 encryption algorithm also serves as the MAC algorithm, and uses the 128-bit tag from Poly1305 as MAC.

3.1. Additional Authenticated Data

The additional authenticated data (AAD) consists of the encrypted packet length.

4. Packet Handling

4.1. Padding

With AEAD algorithms the packet_length field is usually not encrypted using the normal AEAD algorithm, as it needs to be decrypted without knowing how long the packet is going to be.

While the packet_length can be encrypted in a different way, the packet content must be padded without the packet_length field to a multiple of the block size.

As chacha20-poly1305 is a stream cipher and has no block size requirements the minimum SSH alignment requirement of 8 bytes is used instead (see section 6 of [RFC4253]).

The minimum size of a packet (including the packet_length field but not the mac) is 12 bytes (instead of the 16 bytes): the content is padded to at least 8 bytes plus 4 bytes for the packet_length field.

4.2. Receiving packets

When receiving a packet the length must be decrypted first. When 4 bytes of ciphertext length have been received, they need to be decrypted by applying XOR with the packet_length_encryption key for this packet.

The receiver SHOULD verify the packet length (minimum length is 8 bytes, must be a multiple of 8 and must not exceed maximum expected packet length).

Once the entire packet content of further packet_length bytes and the mac has been received, the packet is decrypted as described in [RFC7539].

4.3. Sending packets

To send a packet the packet_length is encrypted by applying XOR with the packet_length_encryption key for this packet. Then the packet content is encrypted as described in [RFC7539] and the Poly1305 tag is appended as mac.

5. Rekeying

AEAD_CHACHA20_POLY1305 must never reuse a {key, nonce} combination for encryption. The nonce wraps around every 2^32 packets, and therefore the same key MUST NOT be used for more than 2^32 packets. The SSH Transport protocol [RFC4253] recommends a far more conservative rekeying every 1GB of data sent or received. If this recommendation is followed, then chacha20-poly1305 requires no special handling in this area.

6. Differences to "chacha20-poly1305@openssh.com"

The chacha20-poly1305@openssh.com algorithm uses the original [ChaCha] specification which varies in the size of the counter and the nonce. Both algorithms concatenate counter and nonce to form a 16-byte input for the ChaCha20 function, but [RFC7539] uses a 4-byte counter and a 12-byte nonce, and [ChaCha] uses a 8-byte counter and a 8-byte nonce.

The counter is a little endian integer which never reaches 2^32^ in the SSH protocol, and the nonce is the big endian encoding of the 32-bit sequence number. Therefore no matter which Chacha specification is chosen the input looks like this:

[little endian 32-bit counter] || 00 00 00 00 00 00 00 00 || [big endian 32-bit sequence number]

The data Poly1305 is applied to in section 2.8 of [RFC7539] differs too: it adds padding and encodes the length of ciphertext and AAD.

7. Security considerations

An attacker can flip single bits in the packet_length field by flipping them in the encrypted data. This is also true for other encryption algorithms like "*-ctr" from [RFC4344] based on XOR.

For further details on the Chacha20 and Poly1305 combination see section 4 of [RFC7539].

8. IANA considerations

Consistent with Section 4.6 of [RFC4250], this document registers the name "chacha20-poly1305" in the Encryption Algorithm Names registry for the encryption algorithm defined in this document.

9. Acknowledgements

The designed is based on chacha20-poly1305@openssh.com and [RFC7539].

10. References

10.1. Normative References

10.2. Informative References

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.

Authors' Addresses