AES vs ChaCha20: Explained While Building Real Crypto Tools

Dhiraj Ray — Tue, 20 Jan 2026 12:23:49 +0000

Over the years, I’ve built and maintained multiple online cryptography tools — AES encryption, ChaCha20 encryption, RSA encryption, and several hashing utilities.

On the surface, all these tools look similar. You provide some input, click a button, and get encrypted or hashed output.

But while working on these tools and reading user comments, I noticed a recurring pattern:

many users are confused about why different encryption algorithms require different inputs.

Why does ChaCha20 need a nonce?

Why does AES talk about modes and padding?

Aren’t they all just “encryption” in the end?

This post is my attempt to answer those questions in a practical, beginner-friendly way.

Encryption Looks Simple — Until You Build It

From a high level, encryption tools feel identical. You enter plaintext, provide a secret key, and receive ciphertext.

But once you implement them, the differences become obvious:

Some algorithms ask for an IV
Some require a nonce
Some expose modes
Others hide complexity to prevent misuse

These differences come directly from how each algorithm is designed.

Why AES Has So Many Options

AES (Advanced Encryption Standard) is a block cipher.

It encrypts data in fixed-size blocks (128 bits at a time).

Because of this, AES must be used with a mode of operation such as CBC, CTR, or GCM.

That’s why AES tools often expose:

Encryption mode
Initialization Vector (IV)
Padding scheme

AES is also extremely fast on modern CPUs thanks to hardware acceleration (AES-NI), which is why it dominates server-side environments.

Why ChaCha20 Needs a Nonce

ChaCha20 works very differently.

It’s a stream cipher, meaning it generates a pseudorandom keystream and XORs it with plaintext.

Instead of modes and padding, ChaCha20 relies on:

A 256-bit secret key
A nonce (number used once)
An internal counter

Users often ask why the nonce matters so much.

The reason is simple: stream ciphers must never reuse the same keystream.

If you want to experiment with nonce reuse and see how output changes, a

ChaCha20 encryption tool

can make this behavior very clear.

AES vs ChaCha20 (Quick Comparison)

Aspect	AES	ChaCha20
Cipher Type	Block cipher	Stream cipher
Random Input	IV (mode-dependent)	Nonce
Modes Required	Yes	No
Padding	Often required	Not required
Hardware Acceleration	Yes	No
Mobile Performance	Good	Excellent

Final Thoughts

AES and ChaCha20 both solve the same problem — turning readable data into unreadable data — but they approach it very differently.

AES shines on servers and compliance-heavy systems
ChaCha20 excels on mobile, browsers, and constrained environments

If you understand why certain fields exist in your encryption tools, choosing the right algorithm becomes much easier.

👉 Read the full in-depth guide with real-world mistakes and FAQs:

https://www.devglan.com/crypto/aes-vs-chacha20

An Introduction to Spring Cloud Gateway

Dhiraj Ray — Sat, 15 Jun 2019 12:02:18 +0000

An API Gateway provides a single entry point for all the microservices running downstream. There are many gateway solutions available such as Zuul, Linkerd, Nginx, etc. but in this article, we will specifically discuss Spring Cloud Gateway - a reactive Gateway built upon Project Reactor, Spring WebFlux, and Spring Boot 2.0.

Zuul Vs Spring Cloud Gateway

Spring Cloud Gateway is a non-blocking gateway while Zuul1 is a blocking gateway. In case of non-blocking, the main thread is always available to serve the request and other multiple threads process those requests asynchronously in the background and once the request is completely processed the response is returned. Hence non-blocking model requires a less no of resources to serve the same amount of requests as compared to blocking gateway.

Though Zuul2 is also a non-blocking gateway but Spring Cloud does not provide integration with Zuul2 out of the box and there are many features in spring cloud gateway that is not available in Zuul2 for publicly such as request limiting.

Spring Cloud Gateway Architecture

Once a request reaches to the gateway, the first thing gateway does is to match the request with each of the available route based on the predicate defined. Once, the route has matched the request moves to web handler and the filters will be applied to the request. There are many out of the box filters provided by the gateway itself to modify the request header as well as the body. Pre-filters are applied specifically to a route whereas global filters can be applied to all the route request. Global filters can be applied to perform authentication and authorization of all the request at one place.

Route Definition in Spring Cloud Gateway

Route the basic building block of the gateway. It is defined by an ID, a destination URI, a collection of predicates and a collection of filters. A route is matched if the aggregate predicate is true.

Below is an example of a route that has a predicate defined to match all the request URL with /api/v1/queue/** and apply a pre-filter to rewrite the path. There is another filter applied to modify the request header and then route the request to load balanced FIRST-SERVICE.

builder.routes()
                .route(r -> r.path("/api/v1/first/**")
                        .filters(f -> f.rewritePath("/api/v1/first/(?.*)", "/${remains}")
                                        .addRequestHeader("X-first-Header", "first-service-header")
                        )
                        .uri("lb://FIRST-SERVICE/") //downstream endpoint  lb - load balanced
                        .id("queue-service"))

                .build();

Below is the equivalent .yaml configuration.

spring:
  cloud:
    gateway:
      routes:
      - id: first-service
        uri: lb://FIRST-SERVICE
        predicates:
        - Path=/api/v1/first/**
        filters:
        - RewritePath=/api/v1/first/(?.*), /$\{remains}
        - AddRequestHeader=X-first-Header, first-service-header

WebSocket Connection in Spring Cloud gateway

The ability to have real-time two-way communication between the client and the server is a key feature in most modern web apps. As we know, Zuul 1 does not support WebSocket connection whereas Spring Cloud Gateway provides excellent and easily configurable support for WebSockets.

Below is a route definition for load-balanced WebSockets. For notification-service, we have a route configured as any request matching with the path /websocket will be routed to notification-service.

.route(r -> r.path("/websocket/**")
                        .filters(f -> f.rewritePath("/websocket/(?.*)", "/${remains}"))
                        .uri("lb://NOTIFICATION-SERVICE/")
                        .id("notification-service"))

There are tons of features provided by Spring Cloud Gateway out of the box. You can get started with this example on Spring Cloud Gateway to know all the features of Spring Cloud Gateway.

Forem: Dhiraj Ray