DEV Community: Supratim Roy

The One-Time Pad: The Only Truly Unbreakable Encryption

Supratim Roy — Tue, 25 Mar 2025 19:53:43 +0000

A classical cipher cannot be truly secure unless it uses an extremely large key, but using such a key is impractical. However, the one-time pad is an exception — it is the most secure cipher available. It guarantees perfect secrecy, meaning that even if an attacker has unlimited computing power, they cannot extract any information about the plaintext except its length.

Although the one-time pad is not practical for everyday use, understanding why it is secure is important. In the 1940s, American mathematician Claude Shannon proved that for a cipher to achieve perfect secrecy, its key must be at least as long as the message. The reasoning behind this is straightforward:

If an attacker had unlimited computing power, they could try all possible keys. However, a properly used one-time pad ensures that every possible plaintext remains equally likely, making it impossible to determine the original message from the ciphertext.

Example:

Plaintext Message: HELLO

Step 1: Convert the plaintext to numbers
We'll use a simple substitution where A=0, B=1, ..., Z=25. So:

H = 7
E = 4
L = 11
L = 11
O = 14
Plaintext as numbers: 7, 4, 11, 11, 14

Step 2: Generate a random key (one-time pad)
The key must be the same length as the message (5 characters in this case) and completely random. Let’s say the key is: KXQWZ

Convert the key to numbers:

K = 10
X = 23
Q = 16
W = 22
Z = 25
Key as numbers: 10, 23, 16, 22, 25

Step 3: Encrypt the message
Encryption is done by adding the plaintext numbers and key numbers modulo 26 (since there are 26 letters in the alphabet):

H (7) + K (10) = 17 mod 26 = 17 (R)
E (4) + X (23) = 27 mod 26 = 1 (B)
L (11) + Q (16) = 27 mod 26 = 1 (B)
L (11) + W (22) = 33 mod 26 = 7 (H)
O (14) + Z (25) = 39 mod 26 = 13 (N)
Ciphertext as numbers: 17, 1, 1, 7, 13

Ciphertext as letters: RBBHN

Step 4: Decrypt the message
To decrypt, the recipient (who also has the one-time pad KXQWZ) subtracts the key numbers from the ciphertext numbers (mod 26):

R (17) - K (10) = 7 mod 26 = 7 (H)
B (1) - X (23) = -22 mod 26 = 4 (E)
(Note: -22 + 26 = 4)
B (1) - Q (16) = -15 mod 26 = 11 (L)
(Note: -15 + 26 = 11)
H (7) - W (22) = -15 mod 26 = 11 (L)
N (13) - Z (25) = -12 mod 26 = 14 (O)
(Note: -12 + 26 = 14)
Decrypted numbers: 7, 4, 11, 11, 14

Decrypted message: HELLO

Why is it Impossible to Break?

Randomness of the Key: The key used in an One-Time Pad must be truly random, as long as the message, and never reused. If the key is random, then every possible plaintext is equally likely, making it impossible for an attacker to determine the actual message.
Key Length Equals Message Length: Since the key is the same length as the message, every bit of plaintext is masked by a different bit of the key. This ensures that no patterns exist in the ciphertext that could reveal information about the plaintext.
Unbreakability by Frequency Analysis: In conventional ciphers, letter frequencies or patterns can help break encryption. Since One-Time Pad keys are random, the ciphertext has no statistical relationship with the plaintext, making frequency analysis useless.
Mathematical Proof of Perfect Secrecy: According to Claude Shannon's proof, One-Time Pad satisfies perfect secrecy because:

P(Plaintext | Ciphertext) = P(Plaintext)

This means knowing the ciphertext does not change the probability of any given plaintext. No amount of computing power can reduce the uncertainty of the plaintext.

Resistance to Brute-Force Attacks: Trying all possible keys in a brute-force attack yields all possible plaintexts with equal probability. Since there’s no way to determine which one is correct, the attacker gains zero useful information.

Limitations of One-Time Pad:

Key Management: Securely generating, distributing, and storing long, random keys is impractical.
Key Reuse Weakens Security: If a key is reused, an attacker can compare multiple ciphertexts to extract information.
True Randomness: Pseudorandom number generators (PRNGs) do not provide the required randomness.

Conclusion:

When used correctly—with truly random, single-use keys—the one-time pad is unbreakable. However, its impractical key management makes it unsuitable for most applications. Since the key must be as long as the message and never reused, encrypting a 1TB drive requires another 1TB drive for the key. Despite this, it has been historically used by British SOE in WWII, Soviet spies, and the NSA, and remains in use for specific purposes today.

Building Resilient Apps: Health Checks in ASP.NET Core

Supratim Roy — Tue, 18 Mar 2025 14:29:05 +0000

In today’s fast-paced digital world, application reliability is critical. A single failure in a database, external API, or caching service can impact performance and lead to downtime. Health checks in ASP.NET Core help monitor the status of your app and its dependencies, ensuring smooth operation and proactive issue detection. They provide a simple way to check system health, notify monitoring tools, and even help with load balancing in cloud environments.

In this post, we'll explore how to implement health checks in ASP.NET Core to keep your application running smoothly and resilient against failures.

In ASP.NET Core, you can implement health checks using the built-in Microsoft.AspNetCore.Diagnostics.HealthChecks middleware. Health checks help monitor the status of your application and its dependencies (like databases, external APIs, etc.).

ASP.NET Core has built-in support for health checks, but if you need UI support or database checks, install additional packages:

dotnet add package AspNetCore.HealthChecks.UI
dotnet add package AspNetCore.HealthChecks.UI.Client
dotnet add package Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore

First, add the health checks middleware in your Program.cs (for .NET 6+) or Startup.cs (older versions):

// Program.cs
var builder = WebApplication.CreateBuilder(args);

// Add health checks
builder.Services.AddHealthChecks();

var app = builder.Build();

// Add health check endpoint
app.UseHealthChecks("/health");

app.Run();

For a more detailed implementation with specific checks, here's an example:

// Program.cs
var builder = WebApplication.CreateBuilder(args);

// Add health checks with specific checks
builder.Services.AddHealthChecks()
    .AddMemoryHealthCheck("memory", maximumMemoryBytes: 104857600) // 100MB
    .AddDiskStorageHealthCheck(setup =>
        setup.AddDrive("C:\\", minimumFreeMegabytes: 1000)) // 1GB free
    .AddUrlGroup(new Uri("https://api.example.com"), "external-api-check");

var app = builder.Build();

// Configure health check endpoint with response
app.UseHealthChecks("/health", new HealthCheckOptions
{
    ResponseWriter = async (context, report) =>
    {
        context.Response.ContentType = "application/json";
        var response = new
        {
            status = report.Status.ToString(),
            checks = report.Entries.Select(e => new
            {
                name = e.Key,
                status = e.Value.Status.ToString(),
                description = e.Value.Description
            })
        };
        await context.Response.WriteAsJsonAsync(response);
    }
});

app.Run();

To add custom health checks, create a class implementing IHealthCheck:

public class CustomHealthCheck : IHealthCheck
{
    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context,
        CancellationToken cancellationToken = default)
    {
        // Your custom health check logic
        bool isHealthy = CheckSomeCondition();

        return Task.FromResult(
            isHealthy
                ? HealthCheckResult.Healthy("System is healthy")
                : HealthCheckResult.Unhealthy("System is unhealthy"));
    }

    private bool CheckSomeCondition()
    {
        // Implement your condition checking logic
        return true;
    }
}

// Register it in Program.cs
builder.Services.AddHealthChecks()
    .AddCheck<CustomHealthCheck>("custom_check");

You can also add health check UI (optional):

// Add NuGet package: AspNetCore.HealthChecks.UI
builder.Services.AddHealthChecksUI()
    .AddInMemoryStorage();

app.UseHealthChecksUI(config =>
{
    config.UIPath = "/health-ui"; // Access at /health-ui
});

Common Health Check Types You Can Add:

.AddSqlServer(connectionString) - SQL Server check
.AddRedis(redisConnectionString) - Redis check
.AddNpgSql(connectionString) - PostgreSQL check
.AddMongoDb(mongodbConnectionString) - MongoDB check

Usage Example:

public class MyService
{
    private readonly IHealthCheckService _healthCheckService;

    public MyService(IHealthCheckService healthCheckService)
    {
        _healthCheckService = healthCheckService;
    }

    public async Task CheckHealthAsync()
    {
        var result = await _healthCheckService.CheckHealthAsync();
        if (result.Status == HealthStatus.Healthy)
        {
            // Handle healthy state
        }
    }
}

Key Points:

Default endpoint is /health
Returns HTTP 200 for healthy, 503 for unhealthy
Can be used with load balancers
Supports dependency injection
Can be secured with authorization

To Test:

Run your app
Navigate to http://localhost:port/health
For UI (if added): http://localhost:port/health-ui

Use Cases:

Application monitoring: Check database, cache, and API status.
Load balancer health checks: Route traffic only to healthy instances.
Kubernetes readiness and liveness probes: Ensure smooth deployments.

Efficient Thread Synchronization in .NET with SemaphoreSlim

Supratim Roy — Tue, 18 Mar 2025 11:34:11 +0000

Why Do We Need Semaphores?

Semaphores are used in programming to control access to shared resources in multi-threaded environments. They prevent race conditions, deadlocks, and excessive resource usage, ensuring smooth execution of concurrent processes.

Key Reasons for Using Semaphores

1. Preventing Race Conditions

When multiple threads access a shared resource simultaneously, it can lead to inconsistent data.
Semaphore ensures that only a limited number of threads can access the resource at a time.

Example: Multiple threads writing to a shared log file might corrupt the log.

2. Controlling Concurrent Access

Semaphores limit the number of threads that can execute a critical section at the same time.
Unlike a simple lock (lock in C#), semaphores allow multiple threads instead of just one.

Example: A database connection pool allowing only 5 concurrent connections.

3. Avoiding Deadlocks

When multiple threads wait indefinitely for a resource, it causes a deadlock.
Using a properly configured semaphore prevents such situations by restricting entry.

4. Managing Resource Usage

Some system resources are expensive (like CPU, I/O, or memory).
Semaphores help optimize usage by allowing only a few threads to access them at a time.

Example:

A print server that processes only 3 jobs simultaneously.
A web scraper that limits concurrent HTTP requests to avoid server overload.

5. Supporting Asynchronous Execution (With SemaphoreSlim)

SemaphoreSlim is useful in async programming to prevent excessive parallel execution while keeping the application responsive.

Example:

An API rate limiter allowing only 10 requests per second.
A background task processor handling multiple jobs efficiently.

What is `SemaphoreSlim`?

SemaphoreSlim is a lightweight, managed version of Semaphore in .NET that is designed for controlling access to a limited resource by multiple threads. It works similarly to Semaphore but provides better performance in asynchronous scenarios.

It is defined in the System.Threading namespace.

Why is `SemaphoreSlim` Useful?

Limits Concurrent Access: It ensures that only a fixed number of threads can access a critical section simultaneously. Useful when managing connections, file I/O, or shared resources like database calls.
Optimized for Asynchronous Programming: Unlike Semaphore, SemaphoreSlim supports the await pattern with WaitAsync(), making it more efficient for async/await workloads.
More Lightweight than Semaphore: SemaphoreSlim does not use kernel-mode objects, making it more performant for in-memory scenarios.
Avoids Lock Contention: Instead of blocking a thread (like lock or Monitor), it allows waiting asynchronously, improving overall system responsiveness.

Example of `SemaphoreSlim`:

Here's a practical example showing how to use SemaphoreSlim to limit concurrent access to a resource (simulating 10 tasks trying to access a resource limited to 3 at a time):

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    // Initialize SemaphoreSlim with 3 concurrent access slots
    private static SemaphoreSlim semaphore = new SemaphoreSlim(3);

    static async Task Main(string[] args)
    {
        // Create 10 tasks to simulate concurrent operations
        Task[] tasks = new Task[10];

        for (int i = 0; i < 10; i++)
        {
            int taskNumber = i;
            tasks[i] = Task.Run(() => DoWork(taskNumber));
        }

        await Task.WhenAll(tasks);
        Console.WriteLine("All tasks completed!");
    }

    static async Task DoWork(int taskId)
    {
        Console.WriteLine($"Task {taskId} waiting to enter...");

        // Wait to acquire the semaphore (blocks if 3 are already in use)
        await semaphore.WaitAsync();

        try
        {
            Console.WriteLine($"Task {taskId} started processing");
            // Simulate some work with random duration
            await Task.Delay(new Random().Next(1000, 3000));
            Console.WriteLine($"Task {taskId} completed");
        }
        finally
        {
            // Release the semaphore slot for other waiting tasks
            semaphore.Release();
        }
    }
}

How it works:

SemaphoreSlim(3) creates a semaphore allowing 3 concurrent entries
WaitAsync() asynchronously waits for an available slot
When a slot is available, the task enters and does its work
Release() frees up the slot when the task is done
Only 3 tasks can execute simultaneously; others wait their turn

Sample output might look like:

Task 0 waiting to enter...
Task 1 waiting to enter...
Task 2 waiting to enter...
Task 0 started processing
Task 1 started processing
Task 2 started processing
Task 3 waiting to enter...
Task 4 waiting to enter...
[Task 0 completes]
Task 3 started processing
[Task 1 completes]
Task 4 started processing
...

This is a thread-safe way to manage concurrent access while being more performant than the traditional Semaphore class, especially in async scenarios.

Modular Monolith: The Best of Both World

Supratim Roy — Tue, 18 Mar 2025 07:28:21 +0000

A Modular Monolith is an architectural style that blends the advantages of both traditional monolithic architectures and microservices. It structures a software application into distinct, loosely coupled modules, with each module handling a specific business capability. However, unlike microservices, these modules are not deployed independently; instead, they are packaged and deployed together as a single unit, like a monolith.

The biggest advantage of a Modular Monolith is its ease of management. Unlike microservices, it does not require Kubernetes or other complex orchestration tools to handle multiple moving parts.

While the application is monolithic in deployment, it is not a tangled "big ball of mud." Instead, it follows a modular structure, where each module functions like a mini-application with a well-defined responsibility. However, all modules are deployed together as a single unit. This approach makes the system both cost-effective and easy to manage.

Data Architecture

In a Modular Monolith architecture, the application is typically deployed as a single unit, which often leads to using a single database shared by all modules as shown in Figure 1. This approach minimizes inter-module communication since all data is centrally available.

When using a single database, organizing data into separate schemas for each module can help isolate their data, improving maintainability and reducing unintended dependencies between modules.

However, if the modules are designed to be independent and serve distinct business functions, they can also have separate databases that store only the data relevant to their specific context as shown in Figure 2. Even in this case, the overall architecture remains monolithic because all modules are deployed together as a single unit.

Module Communication

In this architectural style, direct communication between modules is generally discouraged, though it often becomes necessary in practice. Below are two primary approaches to facilitate module communication, each with its own benefits and trade-offs.

Peer-to-Peer Communication
The simplest approach is peer-to-peer communication, where modules interact directly with one another. Here, a class in one module instantiates a class from another module and calls its methods directly. While this method is straightforward to implement, it has a significant drawback: it tightly couples the modules. Excessive interconnections can erode modularity, leading to a tangled architecture, often leading to the "Big Ball of Mud" antipattern—a system that becomes increasingly difficult to manage and scale.

Aggregator Pattern
A more structured alternative is the aggregator pattern, which introduces an aggregator component as an intermediary layer between modules. Rather than communicating directly, modules send requests to the aggregator, which then routes them to the appropriate destination module.

This approach reduces direct dependencies, enhancing modularity and maintainability. However, while it decouples modules from one another, each module still relies on the aggregator. Although this does not eliminate all coupling, it simplifies the architecture and enforces a controlled, centralized communication structure.

Importantly, the aggregator—not the dependent modules—should provide an API for accessing functionality in other modules. This design keeps modules loosely coupled and preserves a clear separation of concerns.

Example

Here is a typical Modular Monolith example. The solution, named EcommerceApplication, is organized into distinct directories for clarity and modularity. The Applications directory houses deployable applications, such as the Aggregator project, which includes an API along with its associated API.Contracts and API.Tests projects. This directory is designed to accommodate additional deployable applications or user interface, each encapsulated within its own subdirectory.

The Modules directory contains modular components, each residing in a separate subdirectory. This includes InventoryManagement, OrderPlacement, and PaymentProcessing, each with corresponding C# projects. These modules are further structured with Contracts projects that define API contracts and integration events. Additionally, each module includes a Tests project for unit and integration testing.

This structure adheres to a traditional .NET convention, enabling the separation of API contracts into dedicated assembly projects. The Contracts projects not only define the API contracts but also house integration events. For a larger application, these could be further separated to enhance maintainability and scalability.

Advantages

Simpler Deployment: Since it is a single application, you deploy a single artifact. This avoids the complexity of coordinating multiple services, as you would see in microservices, reducing operational overhead.
Easier Debugging and Testing: With everything in one codebase, tracing issues across modules is straightforward. You can run the entire system locally, making integration testing simpler compared to distributed systems.
Performance Efficiency: Modules communicate in-process (e.g., via function calls) rather than over a network, avoiding latency and serialization costs typical in microservices.
Shared Resources: Modules can share a single database, memory, or other resources without needing complex synchronization mechanisms, simplifying data consistency avoiding the need for distributed transactions or eventual consistency models.
Gradual Evolution: It is a middle ground between a traditional monolith and microservices. You can start with a modular monolith and later extract modules into separate services if needed, offering flexibility as requirements grow.
Reduced Overhead: No need for service discovery, API gateways, or distributed logging setups early on, which lowers initial development and infrastructure costs.

Disadvantages

Scalability Limits: Unlike microservices, you cannot scale individual modules independently. The entire application scales as a unit, which can waste resources if only one module is under heavy load.
Coupling Risk: While modules are intended to be loosely coupled, poor design can lead to tight dependencies, eroding modularity and bringing back the pitfalls of a traditional monolith (e.g., spaghetti code).
Single Point of Failure: If the monolith goes down, the entire system is affected. There is no isolation of failures as you would get with separate services.
Technology Lock-In: All modules typically use the same tech stack. If one module would benefit from a different language or framework, you are constrained unless you refactor significantly.
Deployment Bottlenecks: Changes to one module require redeploying the whole application, which can slow down release cycles and increase the risk of introducing unrelated bugs.
Team Coordination: As the codebase grows, multiple teams working on different modules can step on each other’s toes, especially if boundaries are not well-defined or enforced.

When It Works Best

A modular monolith shines for medium-sized applications where you want maintainability without the complexity of a distributed system. It is a pragmatic choice for startups or teams that need to iterate fast but expect growth. If you outgrow it, the modularity makes transitioning to microservices less painful.