Forem: Christian Alt-Wibbing

Post-Quantum Cryptography

Christian Alt-Wibbing — Fri, 24 Apr 2026 07:58:50 +0000

Why the Future of Encryption Starts Today

I have been developing software for over 20 years but what is happening right now is something interesting. Something that genuinely makes me sit up and pay attention.

Quantum computers are no longer science fiction. And with .NET 10, Microsoft has built the answer directly into the platform: Post-Quantum Cryptography (PQC). Quantum-safe encryption that holds up even when quantum computers become a reality.

In this article, I will walk you through what I understand what that means step by step even if you are just starting out in software development.

1. Why Is This Even a Topic?

Imagine you send a encrypted data today. Someone copy the data without decrypt it and waits. In ten years, they have a tool that can decrypt it. Then they read your data.

That is exactly the scenario keeping security experts around the world up at night. It even has a name: “Harvest Now, Decrypt Later.” Attackers collect encrypted data today and decrypt it later, once quantum computers are powerful enough.

The data most at risk is anything that needs to stay secret for a long time: financial information, health records, long-term contracts. If you work in finance, this is not an abstract problem — it is your reality.

2. What Exactly Are Qubits?

Before we go further, let me explain what we are dealing with. I am not an expert in that topic but here is what I understood.

Classical Computers: Bits
A classical computer knows only two states: 0 or 1. That is called a bit. Everything a computer does — writing text, playing videos, encrypting data. Everything is built on billions of these tiny 0-or-1 decisions.

Quantum Computers: Qubits
A quantum computer works with qubits. Thanks to a quantum phenomenon called superposition, qubits can be 0 and 1 at the same time as long as you do not measure them. That sounds strange (and I’m not scientific enough to explain that :) ), but the effect is enormous.

Analogy: Think of a maze. A classical computer tries every path one by one. A quantum computer tries all paths simultaneously. For certain problems, that is exponentially faster.

The result: for certain mathematical problems, exactly those that uses RSA, ECDSA, a quantum computer, is exponentially faster than a classical one. Our current encryption would be broken.

3. The New Standards — International and Official

The good news: The American NIST (National Institute of Standards and Technology) finalised the first three post-quantum standards in 2024. And this was not an American solo project. 82 algorithms from 25 countries were submitted and reviewed by cryptographers worldwide.

In parallel, ISO/IEC and ETSI (the European Telecommunications Standards Institute) are working on their own frameworks. The IETF is currently integrating PQC into core protocols like TLS. This is a global process .

Algorithm	FIPS Standard	Purpose	Replaces
ML-KEM	FIPS 203	Key Exchange (Key Encapsulation)	ECDH
ML-DSA	FIPS 204	Digital Signatures	RSA / ECDSA
SLH-DSA	FIPS 205	Digital Signatures (hash-based)	RSA / ECDSA

4. What Does .NET 10 Do with This?

.NET 10 released in November 2025 as a Long-Term Support (LTS) release — brings these algorithms directly into the familiar System.Security.Cryptography namespace.

No external NuGet package, no third-party library. Just there, ready to use.

As a .NET developer, you now find these new classes:
• MLKem
• MLDsa
• SlhDsa

Even X509Certificate2has been extended: certificates can now contain PQC keys. This is important for TLS and PKI infrastructures.

5. The Hybrid Approach — The Best of Both Worlds

I would advise against switching everything over to PQC overnight. In my experience, new developments need time to prove themselves first. The PQC algorithms are mathematically well-founded and approved by NIST – but they have not yet proven themselves to the same level as RSA, which has been in use for decades.

The solution: the hybrid approach. You combine a classical algorithm (e.g. ECDH) plus ML-KEM simultaneously. If one algorithm is broken, the other still protects you. You are secured against both classical and quantum attacks.

Hybrid = classical algorithm + PQC in parallel. Secure against both attack types.

.NET 10 also supports *Composite ML-DSA * which is a combination of a classical and a post-quantum algorithm in a single signature. This is the recommended transition path.

6. What Does This Mean for Your Project?

Let me be honest: if you have services today that do not encrypt data at all, that is more urgent than PQC. Post-quantum only protects encrypted communication. If data is flowing in plain text, the best quantum algorithm in the world will not help.
My recommended order of priority:

Priority	Action	When
1	Enable TLS for all services, Kafka, RabbitMQ	Today
2	New services directly with ML-KEM + AES (Hybrid)	During .NET 10 migration
3	Migrate internal services to PQC	When both sides are under your control
4	Switch certificates to PQC	When CA + infrastructure are ready

7. What About the IdentityServer?

Many projects use Duende IdentityServer for authentication — with JWT tokens signed using RS256 (RSA + SHA-256). That is exactly the algorithm a quantum computer could break.
The goal: add ML-DSA as an additional signing algorithm — alongside RS256, not as a replacement. Why alongside? Because older clients expect RS256 and do not yet understand ML-DSA.

⚠️ Important:
Duende IdentityServer must explicitly support ML-DSA. This is a dependency outside your control. Keep an eye on the Duende roadmap!

8. My Personal Conclusion

After years of software development, I have learned: the biggest security problems do not arise from missing technology but they come from acting too late. PQC is not a “someday” topic. It is a “prepare now” topic.

.NET 10 makes it easy for us: the algorithms are there, they are standardised, they are internationally recognised. The entry point is manageable. And anyone currently migrating to .NET 10 has the perfect opportunity to incorporate PQC at the same time, no extra overhead.

Start with what matters most: encrypt first. Then think about PQC. And then you will be ready for what is coming.

Sources & Further Reading

• Post-Quantum Cryptography in .NET — .NET Blog (Microsoft)
• .NET 10: Post-Quantum Cryptography Comes to .NET — Anthony Giretti
• NIST Releases First 3 Finalized Post-Quantum Encryption Standards
• ML-KEM and ML-DSA Post-Quantum Cryptography in .NET — Strathweb
• Post-Quantum Cryptography — NIST (international adoption)
• What’s new in .NET 10 — Microsoft Learn

Minimal APIs, Controllers & FastEndpoints Compared

Christian Alt-Wibbing — Wed, 22 Apr 2026 06:25:36 +0000

What is this about?

When you build a new API in .NET 10 today, you face a decision that didn’t exist before: Minimal API, classic Controllers, or FastEndpoints? All three are fully capable approaches — but they have different strengths, weaknesses, and use cases.
In this post, we take an honest look at all three.

Minimal APIs — lean, modern, fast

Minimal APIs were introduced with .NET 6 and have evolved significantly since then. In .NET 10, they have truly come of age.

The simplest endpoint in the world

app.MapGet("/ping", () => "pong");

That’s a complete API. One line. No controller, no class, no attribute.

What’s new in .NET 10?

Built-in Validation Previously you had to either pull in FluentValidation or write your own checks. Now a simple call is enough:

builder.Services.AddValidation();

Your DTO with DataAnnotations is then automatically validated — and on failure, a clean ProblemDetails response is returned. No more manual if-statement juggling.

Endpoint Filters instead of Action Filters

Instead of Action Filters, Minimal APIs use Endpoint Filters. The concept is similar — logic before or after the handler — but less powerful:

app.MapPost("/orders", Handler)
     .AddEndpointFilter<LoggingFilter>()
     .AddEndpointFilter<ValidationFilter>();

Filters run from outside in — like middleware onions. For logging, validation, and simple auth checks, this works well. For complex result manipulation, it gets tricky.

The biggest advantage in my opinion: Native AOT

Minimal APIs support Native AOT (Ahead-of-Time Compilation) — Controllers do not. That means: no JIT at runtime, lightning-fast startup, less memory, smaller deployments. A real game-changer for Lambda functions, Kubernetes pods, or edge deployments.

Extracting endpoints — the Extension Method trick

A clean solution for larger projects: move endpoints into their own > classes and register them via Extension Methods:
public static class OrderEndpoints {     
  public static WebApplication MapOrderEndpoints(this WebApplication >app){
     app.MapPost("/orders", HandleCreate);         
     app.MapGet("/orders/{id}", HandleGet);         
     return app;     
  } 
}
Program.cs stays clean:
app.MapOrderEndpoints(); 
app.MapProductEndpoints(); 
app.MapCustomerEndpoints();

Controllers — proven, structured, complete

Controllers are the classic approach in ASP.NET Core. They’ve been around for years, are well documented, and every .NET developer knows them.

What Controllers do better

Action Filter Pipeline — this is the biggest difference. Controllers have

OnActionExecuting,
OnActionExecuted,
OnResultExecuting

very fine-grained control over different phases of the request lifecycle.

Direct Unit Testability — you can instantiate a controller directly and test it without spinning up the entire HTTP stack:
var controller = new OrdersController(mockService); var result = controller.Create(request);

Proven Structure — one class per resource, methods per action. New team member? They’ll find their way around immediately.

What Controllers cannot do

No Native AOT support — Controllers rely too heavily on Reflection, and Reflection is incompatible with Native AOT. This is a fundamental limitation, not a bug.

FastEndpoints — the best of both worlds

FastEndpoints is an open-source library that builds on top of Minimal APIs — but gives you a clean, structured development experience on top.

The REPR Pattern

The core concept is the REPR Pattern — Request → Endpoint → Response. Each endpoint gets its own class. Not one controller class with 10 methods — but truly one class per endpoint:

public class CreateOrderEndpoint : Endpoint<CreateOrderRequest> 
{     
   public override void Configure(){
         Post("/orders");
         AllowAnonymous();     
   }      
   public override async Task HandleAsync(CreateOrderRequest req,
                                          CancellationToken ct)
   {
         await SendOkAsync("Order created");     
   }
}

You can see: it has the structure of Controllers — a class, clear methods — but the performance of Minimal APIs underneath.
What FastEndpoints brings
• Built-in Validation with FluentValidation — directly integrated
• Filter System — similar to Action Filters, cleanly implemented
• Performance on par with Minimal APIs — noticeably faster than Controllers
• Native AOT Support — because it builds on Minimal APIs

The trade-off

FastEndpoints is an external dependency. You’re bringing in a library with its own concepts. New team members need to learn it. The community is smaller than for Controllers or Minimal APIs.

Conclusion — which one should I pick?

The honest answer: it depends. But here’s a simple rule of thumb:
• Minimal API → Small, fast, modern. Perfect for microservices and cloud-native.
• Controllers → Large, proven, structured. Perfect for large teams and complex projects.
• FastEndpoints → The best of both worlds — with an external dependency as the price.

And the great thing: all three can coexist in the same app. You can start with Minimal APIs and migrate to FastEndpoints later — or keep Controllers for complex parts and use Minimal APIs for simple endpoints.

For further information you can read following Sources

Vibe Coding – The Revolution of Software Development or Just a Hype

Christian Alt-Wibbing — Fri, 09 May 2025 13:00:39 +0000

In the fast-paced world of software development, new buzzwords and trends are constantly emerging. One of the hottest current topics is something called Vibe Coding. But what’s behind this term that’s dividing opinions—praised by some as revolutionary, dismissed by others as “total garbage”?

What is Vibe Coding, really?

The term Vibe Coding was coined in February 2025 by computer scientist Andrej Karpathy, co-founder of OpenAI and former AI lead at Tesla. He described it as a conversation-based approach where spoken commands are used while an Artificial Intelligence (AI) generates the actual code. Karpathy himself said:

It's not really coding - I just see things, say things, run things, and copy-paste things, and it mostly works.

At its core, Vibe Coding describes a programming technique that relies entirely on AI to write source code, making programming accessible even to those without experience. Instead of manually coding, the user describes a problem in a few sentences as a prompt for a large language model (LLM) with sufficient programming knowledge. The LLM then generates the software, shifting the programmer’s role from writing code to guiding, testing, and refining the AI-generated output.

From Hobby Projects to Startup Codebases

Vibe Coding allows even inexperienced users to create software prototypes without deep training or technical skills. It's gaining traction for its ability to rapidly turn ideas into prototypes with minimal technical effort.

However, experts warn that the results are often limited and error-prone. In one case, AI-generated code produced fake reviews for an e-commerce site. Roose suggested that Vibe Coding is better suited to hobby projects than to mission-critical tasks.

The Potential of Vibe Coding

Faster from idea to prototype: Vibe Coding can significantly lower the barrier between an idea and working software. People without coding experience can bring their visions to life quickly.
Focus on the idea: Instead of getting lost in technical details, users can focus on the functionality and user experience of the application.
Increased efficiency: Even professional developers can use Vibe Coding to generate boilerplate code or quickly build first versions of software.
Learning effect: Interacting with AI-generated code can give non-technical users a basic understanding of software development.

Challenges and Criticism

Despite the potential benefits, there are major concerns and criticisms around Vibe Coding:

Understanding: Developers might use AI-generated code without fully understanding how it works, leading to undetected bugs, malfunctions, or security flaws.
Quality and maintainability: LLMs often produce code without considering architecture, reusability, or maintainability. The result can be unclear and inconsistent code.
Security risks: Blind trust in AI-generated code can lead to security vulnerabilities, like accidentally leaking API keys.
Loss of coding skills: Overreliance on AI may result in a loss of programming proficiency and dependency on AI tools.
Accountability: It's often unclear who is responsible for errors or security issues in AI-generated code.

Some voices in the developer community are highly critical of Vibe Coding. In one Reddit thread, it was labeled “total garbage.” Others expressed concerns over the loss of learning processes and the neglect of security practices.

Tools Supporting Vibe Coding

Despite criticism, a growing number of tools and platforms are making Vibe Coding more accessible:

IDEs with AI integration: Tools like Cursor enable direct interaction with AI models for code generation.
VS Code extensions: The Cline plugin brings AI features into the popular VS Code editor.
Online code editors: Replit offers a web-based IDE with built-in AI agents capable of generating full applications from natural language prompts.
AI assistants with canvas features: Platforms like Claude, ChatGPT, and Google AI let users write and run code directly in the browser.
Dedicated Vibe Coding platforms: Replit also offers easy deployment and integrated cloud services for quick project launches.

Conclusion: More than just a Vibe?

Vibe Coding is trending—and it could significantly change the way we develop software. It enables faster development and lowers the barrier for those without much experience.

But: blindly trusting code written by AI can be risky. It might have errors, be insecure, or hard to understand.

Most likely, the future will be a mix of traditional programming and AI-assisted tools. Vibe Coding is great for quick tests, small apps, or automating boring tasks. For critical or complex projects, however, a deep understanding of the code and thorough review is still essential.

Whether Vibe Coding turns out to be more than just a short-lived trend remains to be seen.

What matters most is to stay open to innovation—but also to approach it carefully and thoughtfully.

Software Development: Art, Science, and Gardening

Christian Alt-Wibbing — Fri, 09 May 2025 12:37:14 +0000

"Is software developed or cultivated?" This question brings an intriguing perspective to the world of software development. When we write software, do we follow strict methods, or is it a creative, artistic process? And what does it mean to treat a software system like a garden?

Art and Science: Two Perspectives on Software Development

In the debate over whether software development is an art or a science, it quickly becomes clear how much our perspective shapes our thinking and approach. When we see software development as a science, we emphasize structured, reproducible processes and precise results created through clear rules. In science, we often seek the best, reproducible solution, based on data and analysis. In software development, this might mean relying on design patterns, algorithms, and a strict adherence to best practices that streamline the development process.

On the other hand, there’s the artistic approach: Here, it’s less about following rules and more about creativity, expression, and problem-solving from various, often innovative perspectives. Just as artists shape a blank canvas, developers bring their ideas to life through code, exploring new paths and making choices that go beyond mere functionality. Solutions may be elegant and unique, but they often reflect personal preferences, leading to different styles and approaches.

A Living Organism: Understanding Software as a Garden

In his book Code That Fits in Your Head, Mark Seemann offers an intriguing alternative: Instead of seeing software solely as art or science, we might think of it as a living organism or a garden. A garden isn’t static – it grows, changes, and without regular care, it can become overgrown.

For software, this means that without regular refactoring and removal of obsolete elements, a codebase gradually loses structure and clarity. An overgrown garden is difficult to manage and ultimately costs more time and effort. By viewing software development as continuous maintenance, we work proactively to keep the system stable and sustainable – striking a balance between the precision of science and the creativity of art. But just like any garden, this raises the question of how much maintenance is enough, and when does it become too much? Even an overly groomed garden can look crowded and chaotic.

Looking to the Past: The Journeyman's Years as a Model for Learning Developers

An inspiring idea is to revisit the European tradition of the journeyman's years, also known as the “Wanderjahre” or “Walz” in germany. In the past, craftsmen would travel from town to town, learning from different masters and gaining valuable experience that shaped their skills and style. Applied to software development, this approach could mean that developers benefit from working on diverse projects, with various mentors and teams, to learn new ideas and techniques. This approach preserves flexibility and fosters a broad understanding of different problem-solving methods.

The Risk of Overengineering

"The brighter the light, the darker the shadow."

When efforts to make software “perfect” go too far, extra abstractions and complexity can unnecessarily bloat the system. As knowledge and skills grow, so too does the risk of overengineering. The more tools and techniques a developer masters, the greater the temptation to craft solutions that are more complex and intricate than necessary. This drive to make everything perfect and "elegant" can make the code unnecessarily complicated and hard to maintain. A well-maintained “garden” is only as complex as needed and as simple as possible.

Conclusion: Striking a Balance between Structure and Creativity

Ultimately, the art of software development lies in balancing these different approaches. Guidelines and best practices create a framework that elevates software development to engineering, while still leaving room for the creative freedom that enables innovative and elegant solutions. A sustainably maintained "software garden" relies on retaining an overview, eliminating outdated structures, finding the right balance between creativity and discipline, and occasionally switching teams or projects.

How do you maintain your code? Do you strictly adhere to scientific methods, or do you see your work as artistic expression? Share your views and experiences in the comments – how do you keep your codebase maintainable and elegant?