Hardware-based security for high-level protection.

XIP2113H: ChaCha20-Poly1305, high-speed version

High-Speed IP Core for ChaCha20-Poly1305 Authenticated Encryption


XIP2113B from Xiphera is a high-speed Intellectual Property (IP) core designed for ChaCha20-Poly1305 Authenticated Encryption with Associated Data (AEAD) scheme protecting both confidentiality and authenticity at the same time. The current definitive standard for ChaCha20-Poly1305 is RFC 8439, “ChaCha20 and Poly1305 for IETF Protocols”.

ChaCha20-Poly1305 is a combination of the ChaCha20 stream cipher and Poly1305 message authentication code, both algorithms designed by Daniel J. Bernstein, and it is used an AEAD scheme in multiple protocols, including TLS 1.3.

XIP2113B has been designed for easy integration with FPGA- and ASIC-based designs in a vendor-agnostic design methodology, and the functionality of XIP2113B does not rely on any FPGA manufacturer-specific features.

Key features

  • Moderate resource requirements: The entire XIP2113B requires 14928 Adaptive Lookup Modules (ALMs) (Intel ® Agilex ® F).
  • Performance: XIP2113B achieves a throughput in the tens of Gbps range [1], for example 43.52+ Gbps in Xilinx ® Versal ® Prime. Even higher throughputs can be achieved with parallel instantiations of XIP2113B.
  • High Throughput with Short Latency: XIP2113B offers very high throughput for a single stream of data as it is capable to process one 16-byte block per clock cycle after certain initial latency. The length of the initial latency depends on the length of the message and XIP2113B has been carefully optimized to minimize this initial latency.
  • Constant Latency: The execution time of XIP2113B is independent of the key values and message contents (apart from the message length), and consequently provides full protection against timing-based side-channel attacks.
  • Standard Compliance: XIP2113B is fully compliant with RFC 8439 “ChaCha20 and Poly1305 for IETF Protocols”.


The input message into XIP2113B is split into two parts: the first part is only authenticated and the second part is both authenticated and encrypted (or decrypted) [2]. For example, the first part can be the header of a packet and the second part can be the payload. This way the header remains in cleartext and can be used, for instance, for routing the message to the correct recipient. However, the header is still authenticated and the recipient can verify that it has not been tampered with. The first part is called associated data and the second part is message payload (either plaintext or ciphertext).

The output of ChaCha20-Poly1305 is the associated data (AD, without padding, just as it was inputted), the encrypted payload (without padding), and the 16-byte authentication tag. In the decryption direction, the computation is similar, but Poly1305 takes the ciphertext before it is XORred with the keystream. In the end, the authentication tag that is computed during decryption is compared with the received tag. If they match, the received message is authentic; if not, it should be rejected.

XIP2113B uses a 256-bit key and a 96-bit nonce. They are used directly as the key and nonce for the ChaCha20 stream cipher. The key for Poly1305 is computed with ChaCha20 by setting the counter value to zero and by using 256 bits of the 512-bit keystream word k0 as the Poly1305 key; the other half is discarded. As the computation of this authentication key depends on both the key and the nonce, the authentication key needs to be recomputed for every message even if they are encrypted with the same key.

For more technical and commercial details, including FPGA resources & peak performance as well as ordering instructions, open the full product brief in PDF. Contact us by sending and email to email_career.png, and we’ll get back to you as soon as possible.

Open full product brief

Block diagram

Figure 1: Internal high-level block diagram of XIP2113H

Figure 1: Internal high-level block diagram of XIP2113H.


[1] The highest throughput is achieved for long messages.

[2] Both the first path (authentication only) and the second part (authentication and encryption/decryption) can also be zero bytes long.

Visit the product family page