DEV Community: Alberto Boffi

Move Fast, Fail Fast, Judge Fair: Why Tech Needs Outcome-Based Responsibility

Alberto Boffi — Fri, 28 Aug 2026 17:12:07 +0000

Why I Think We're Judging Engineers the Wrong Way

I've been thinking about this topic for a while, and I believe it deserves a closer look.

The way we attribute responsibility has a direct impact on how engineers perform and what they produce. And yet, the criteria most companies use to judge responsibility haven't kept up with how the best teams actually work today. Over time, several conditions have been proposed to evaluate responsibility, as wrong-doing, foreseeability or freedom of action. These conditions allow us to decide whether someone can be considered "responsible" for a certain situation, and to which extent, so we can estimate the seriousness or commendability of his actions. But these are guidelines built on outdated mindsets. What I want to propose here is a different method: an individual is always fully responsible for what he causally contributes to, regardless of the way he achieves a certain result or the intentions. The seriousness or commendability of his actions is only given by the consequences they cause. My goal is to show that it's always necessary to adopt this approach if we want the individual to work according to modern professional values.

What Do We Actually Mean by "Responsibility"?

With "responsibility" I simply mean being held blameworthy for some unwanted circumstances, or even praiseworthy for the occurrence of a desired event. There are different ways to slice it. A first, fundamental distinction is between active responsibility (responsibility before something has happened) and passive responsibility (responsibility after something has happened). You can also look at it through different lenses: professional, moral, or role-based.
Throughout this article I will always implicitly refer to professional passive responsibility. "Professional" means that I'll focus on the responsibility someone has as a professional, in particular as a professional engineer. I'm not trying to generalize my view to any other context. "Passive" means that I'll analyze how an individual can be held responsible for a certain result, only when that result has been produced. Nevertheless, let's see how the way we judge passive responsibility impacts the way the individual approaches his job in the first place.

Why Causal Contribution Is the Only Thing That Matters

There's a pretty universal agreement on this: the basic condition for a person to be held responsible for a given event, is that he has causally contributed to the occurrence of that event. To understand the concept of "causal contribution", we can model it through this simple statement:

A subject performs an action. The action causes a result.

The "action" refers to any activity or decision a human being can take, such as drinking a coffee or driving a car. However, for our purposes, we are interested in professional actions related to a specific engineering context. For a software engineer, it could be the implementation of a new feature in a mobile application; for a mechanical engineer, the improvement of the efficiency of a certain hydraulic component. Keep in mind that even the decision not to act is usually considered an action.
The action performed by the subject generates a "result", that is, the new setting of reality that would not have existed if the subject had not performed the action in the first place, regardless of the intentions.
Whenever we have to attribute responsibility for a certain result, the "subject" is the person to be investigated.

And this is where it gets interesting. The essential question is whether, in investigating the subject's responsibility, it is sufficient to consider the result or should we also analyze the action.
At the moment, we are used to looking at the action. There have been several attempts to propose conditions that touch both the way the action has been performed, and the motivations behind it (we can for instance mention wrong-doing, foreseeability or freedom of action, all conditions related to blameworthiness). They allow us to establish whether the subject is responsible for a certain result, and to which extent. The extent to which he is responsible can also be seen as the seriousness (in case of an unwanted result) or the praiseability (in the case of an expected result) of his actions. If we think about it, in a professional environment this plays a fundamental role, as it can be seen as the main root of promotions or firings.
But I firmly believe that this approach is no longer suitable nowadays. What I want to show from here on is how, in modern society, the only reasonable choice is to ignore the action to just focus on the result. In other terms, the subject is always fully, totally responsible for the result he produces. This means that an action is as serious or praiseworthy as the result it causes.
Of course, saying "in modern society" is very vague, and it would be difficult (if not impossible) to prove that my thesis holds for every professional field, company culture and place in the world. So here's my approach: I am going to identify the most revolutionary professional culture, adopted by today's most successful companies. I'll then show that the proposed approach is the best choice to complement this culture. If this culture represents most of the professional world not only today, but ever more in the future, the validity of my thesis will follow.

The Work Philosophy That Changed Everything

If you've worked in tech or followed the industry closely, you've seen this firsthand. In the last decade, many big tech companies such as Google, Meta, Amazon or Tesla have based their success on a work philosophy built around moving fast and failing fast. It's the classic tech mindset: prioritize rapid iteration, embrace risk, and accept failure as a necessary part of innovation. We can break down this philosophy by isolating the method it proposes, and the result it aspires to obtain.

Method
The method consists of three ingredients: risk, failure tolerance and speed.
One must constantly take risk and fail, attempt after attempt, without worrying about what the final result will be. Moreover, this has to be done by moving as quickly as possible, favoring a fast result over a perfect one.

Objective
By the experience and skills acquired through this process, in the long run the company will boast products of the highest quality, obtained much earlier than companies that focus on great results in the short term.

To be clear, this article is not about discussing whether this approach is good or bad. For instance, it may not be a good idea for mission-critical businesses, like pharmaceutical companies. The point is that it seems to have proved successful for its adopters, and that's why it appears to be rapidly expanding.

How You Judge People Changes How They Work

Let me walk you through a thought experiment that can be concretely replicated in many real life situations. In this thought experiment, we have two subjects, or employees, that are working on the same long-term project, no matter what it is. We can assume both subjects have the same skills, experience and education background, so that neither has an advantage over the other. We then imagine that there is no way in which the two can come into contact, for the entire duration of their work. This means they can't communicate, exchange opinions or motivations. They can for example work in different companies, or in completely separate sections of the same company, under a different management.
Both are supposed carry on the project by adopting this "move fast and fail fast" approach.
Once the projects have been completed, they are judged "responsible" to some extent for what they have produced (whether good or bad) according to a chosen criterion. For the entire duration of their work, both subjects are aware of the criterion that will be used. Two things will happen:

They will be rewarded in proportion to what they have produced good, and to the extent they are responsible for it;
They will be penalized in proportion to what they have produced bad, and to the extent they are responsible for it;

Their goal is to maximize the reward and minimize the penalty.
The only difference between the two subjects is that, for each of them, we use a different criterion to attribute responsibility. We evaluate the responsibility of the first subject by analyzing the course of actions that led to the final outcome. In the second case, instead, the subject is always fully responsible of the outcome.
The goal is to see how this difference impacts the way each subject approaches his task, and in which case the performances are maximized.

About the first subject, we can for instance verify that he followed the standard procedure without violating any norm, or if the intentions matched the final result. This would mean potentially justify him for the occurrence of a certain bad situation, or, conversely, (partially) deprive him of the recognition for a success, if it was achieved in a way considered "inappropriate".
In response, the subject will behave accordingly, by also placing his attention on the actions he carries out to complete the project. What does this do to his "move fast" approach? Let's break it down:

Method
The subject will try as much as possible to follow a course of action that is in line with a certain standard. He will also make decisions that can be sufficiently motivated, refraining from hunches and intuitions. As a consequence, the risk factor is almost completely absent.
There's also the foreseeability problem: to be able to justify his choices a posteriori, the subject will not take any action without being aware of the consequences. This is in contrast to the "fail fast" principle of "doing something without worrying about the outcome" mentioned earlier, upon which the failure tolerance factor is based.

Objective
Following a course of action that doesn't deviate too much from the norm, the subject's approach to his job won't undergo significant mutations. As a consequence, the quality of what he produces is not going to improve much over time. In other words, he'll not reach the objective of retaining the highest quality product in the long run.

In the second case, the result of the subject's causal contribution is all we need to know. Inevitably, the subject's focus will entirely be on the final value of its realization. Let's see what happens here:

Method
As a first effect that we can imagine, the subject will exploit his skills or experience by using his intuition to achieve the desired scope, instead of relying on the "correct way of acting". This has a significant impact on the execution speed.
We can then reason on the risk factor. We all know, from life experience, that some of the most ambitious goals have risk as the price to pay. If the result is all that matters, we can expect the subject to have the courage to break through this barrier, by embracing risk without much hesitation.
In turn, risk leads to failure tolerance, as by definition risk carries the possibility of failure.

Objective
Over time and during each attempt, the subject will adjust his working strategy with the sole purpose of improving the outcome. The effect is a faster progress and better results in the long run.

So here's what we see: looking at the action performed by the subject leads to a reduction in the risk and failure tolerance factors of this method, and prevents the achievement of the objective. On the contrary, evaluating only the outcome incentivizes the speed, risk and failure tolerance factors, prompting the achievement of the long-term objective.
The takeaway is clear: with equal preparation, skills and experience between the two subjects, by simply shifting the evaluation of responsibility to the new approach, the second subject will better meet the requirements of performance and job management.
But I understand that for some of you this may not be enough. This is indeed a sensitive topic. For this reason, in the next section I will try to anticipate and answer some of the possible objections.

Addressing the Pushback

Here's how I've organized this: the first two objections are about why it might still be useful to evaluate the actions performed by the subject. The other two go after the core argument itself. The third one argues that my approach to responsibility is not really useful under "move fast and fail fast" conditions, and the fourth that it doesn't hold outside of them.

"But What About Ethics?"

The objection goes like this: although it promotes speed and quality, using the result as the only judgment metric is unethical, as it justifies immoral and bad actions performed for the sole purpose of obtaining the desired result.
This is an interesting objection, but it needs to be further analyzed. For instance, one may argue if the action can be really defined as "immoral" if useful to obtain a good result. Can a doctor's disobedience to the hospital rules be considered immoral if it saves a patient's life? This forces us to make a distinction between what is good for a company and what is good for the society or the welfare of the people around us. In this framework, causing physical or moral harm to another person for the purpose of bringing more money into the company coffers can be safely consider "immoral".
But if we do this distinction, we must do it also for the results of the subject's causal contribution. In other terms, the subject causally contributes to bringing more money into the company coffers, but he also causally contributes to causing harm to the person. The damage to the welfare of the society is no longer an action, but becomes another result of the action, for which the subject must be held responsible in the same way.
We can of course say that some modern companies ignore this kind of results, but that's a different debate entirely, and it's completely independent from the way we attribute responsibility.

"What If Someone Is Forced to Act?"

This is a fair point: the subject cannot be considered responsible whenever he acts under coercion, or against his will. Indeed, we've seen that a subject is only responsible for what he causally contributes to. But if the causal contribution has been forced, it would be illogical to still consider him "responsible".
I am not of the opinion that an individual is less responsible for what he causes whenever he doesn't act freely. But in any case, this objection has actually little to do with the thesis of this article. Here's why: dealing exclusively with professional responsibility, it mainly refers to the case where the employee is threatened with being fired or not promoted. However, even people who raise this objection tend to agree that the coercion must be stricter than a simple salary cut. Even if we wanted to consider it as a valid coercion, at that point we should balance professional responsibility with the moral (and role) responsibility that the employee has in providing a salary for himself and/or his family. That's a whole different rabbit hole, and this would require a more extensive study.
So I'll leave this one here.

"Doesn't This Make People More Afraid to Fail?"

This one is probably the strongest pushback. It's intended for all those who argue that the thought experiment presented above is wrong, and so the new proposed approach to responsibility is not the best choice to incentivize a "move fast and fail fast" philosophy.
The reason behind this theory may be the following: by evaluating responsibility only on the basis of the result, the subject will be more afraid of making mistakes, even when he is aware of his own potential. He'll thus avoid taking risks and moving quickly, negatively affecting the method and, in consequence, the long-term objective.
This objection can be easily answered by clarifying, once again, the meaning of this philosophy. Like any other corporate culture, a "move fast and fail fast" culture aims to achieve high quality results. However, the key difference is that it only requires them over the long term. In the short term, whenever the subject approaches a new venture, failure is not only accepted, but also encouraged. Actually, this attitude is really meant to undermine the fear of making mistakes. Of course, this does not mean that the subject will be less responsible for his own results in the short term. It just means that he won't be punished for them. As a consequence, he will be driven to move freely and boldly in pursuit of his goals.
This is the reason why, in the proposed thought experiment, the subject is rewarded or penalized only upon completion of his project.

"This Only Works in Silicon Valley"

At this point, many could be convinced of the validity of my thesis in a "move fast and fail fast" context. But they could argue that, as much as this culture may expand, it's currently not adopted everywhere. Even in the future, it's reasonable to think that there will always be areas where it'll not be introduced. For this reason, my thesis cannot be generalized, as it would lead to undesirable results in the rest of the world.
Let me reiterate why I decided to focus on a single business culture. The aim was not to "find a business culture that needs a new approach to assessing responsibility", but instead: "in order to prove the need for a new approach to assessing responsibility, consider the most influential business culture to show that, in such an environment, this is true.". In other words, it was only a practical matter, as it would have been impossible to focus on every possible engineering context. That said, the way this objection is worded is actually incorrect. It assumes that, wherever this philosophy is not adopted, my thesis is incorrect. But this is not necessarily true. It just means that its effectiveness has not yet been proven or disproven. Honestly, the best I can say is that, in case the analysis will be extended to other industrial realities, it is plausible that my thesis will be further confirmed.

Where This Leaves Us

In this article, I laid out a different way to think about professional responsibility. I showed how it can benefit the way the most successful companies operate today, and I tried to address the strongest pushback I could think of. That said, this is far from a closed case. There are professional realities I haven't covered, and the natural next step is to extend this analysis to them.

So here's what I want to leave you with: next time you evaluate someone's work, or your own, ask yourself whether you're judging the process or the outcome. And if the answer is the process, ask yourself why. Does your company, your team, your industry truly benefit from that?

The Modern PWA Blueprint [Part 5]: SDLC Costs, ROI & The Final Decision Framework

Alberto Boffi — Thu, 20 Aug 2026 16:54:23 +0000

The Economics of PWAs: Slashing Development & Maintenance Costs

The financial framework which facilitates the upkeep and development of a PWA gives a significant strategic advantage, especially because of its basis in established web development practices. This approach typically yields enormous savings in terms of cost as well as time compared to native application development.

Initial Development: One Team, One Shared Codebase

The primary driver of cost savings is the adoption of a shared codebase. Instead of spending resources on separate development teams for iOS and Android, a single team of web developers can produce one application that runs flawlessly across all platforms. This consolidation dramatically reduces both development time and the complexity inherent in project management.

Furthermore, PWAs are built with ubiquitous technologies like HTML, CSS, and JavaScript, along with popular frameworks such as React, Angular, or Vue. This means there is a vast pool of developer talent available, making it easier and often more cost-effective to staff a project compared to finding specialized native mobile developers.

Another key aspect involves avoiding traditional application distribution stores. This strategy avoids the monetary costs involved with app store submission costs (e.g., the recurring cost of the Apple Developer Program) and, more importantly, avoids the typically long and, at times, uncertain review and approval processes. This reduces the time to market and frees up resources otherwise spent on coordinating submissions to such platforms.

Long-Term Maintenance: Zero Store Gatekeepers, Instant Rollouts

The effectiveness of the PWA model becomes more pronounced in long-term support scenarios. Upgrade processes become streamlined and cost-effective by virtue of:

No app store approvals are needed, enabling continuous deployment and rapid iteration cycles.
There's an independent version of the program available constantly on-line, enabling instant execution of corrective patches or additional features to all users.
There is no necessity to manually update users' software to gain access to the newest version.

In the long term, it creates less operational complexity, more efficiency in quality testing and assurance protocols, and fewer infrastructure costs.

The Verdict: When Should You Build a PWA?

Progressive Web Applications are a viable option over native and hybrid development. They provide seamless access, reduced costs for development and maintenance, and faster deployment times. They support offline functionality, push notifications, and can be installed directly from a browser, making them akin to both web and native applications. While PWAs might not be able to offer the same level of performance or integration with hardware as native applications, these applications perform satisfactorily in scenarios where reach, flexibility, and cost matter most. As browser capabilities continue to advance and support for various platforms become more universal, PWAs are going to have a significant impact in app development in the future, especially for enterprises seeking solutions that are scalable, simple to maintain, and are not platform-specific.

If you are evaluating whether a PWA fits your next project, I hope this breakdown gives you a clearer starting point. What KPI matters most in your specific context?

The Modern PWA Blueprint [Part 4]: In-Browser AI, Accessibility & SEO

Alberto Boffi — Thu, 20 Aug 2026 16:53:46 +0000

Supercharging PWAs with AI: Cloud APIs to In-Browser Models

PWAs are exceptionally well-suited to integrate with modern AI and machine learning tools, thanks to their foundation in the open and flexible web ecosystem. Whether using cloud-based AI APIs or running models directly in the browser, PWAs can leverage both server-side and client-side AI solutions without major architectural constraints. Developers can mix server-side and client-side approaches to best fit their needs.

Server-Side AI: LLMs, APIs & Cloud Vision

This is the most straightforward and powerful method for embedding advanced AI. PWAs can easily call external APIs from major cloud providers for a wide range of tasks. This includes:

Generative AI and NLP: Calling services like OpenAI API, Google Cloud AI (Gemini, Vertex AI), Microsoft Azure AI, or AWS AI Services for text generation, translation, vision, or speech processing.
Conversational User Interfaces: Including chatbot solutions such as Google Dialogflow or Rasa.
Personalization: Enabling recommendation systems and personalized search by utilizing REST or GraphQL interfaces.

In-Browser AI: Edge Models, WebAssembly & WebNN

For real-time, low-latency, and privacy-focused applications, PWAs can run AI models directly in the browser using TensorFlow.js, ONNX.js, or WebAssembly-based runtimes. Because a PWA's service worker can cache the AI model, these features can even work offline. Furthermore, PWAs can seamlessly combine client-side AI with other modern browser APIs for powerful interactive experiences. Two of the most common examples:

WebRTC and camera/microphone functionality: Used for real-time audio and video data processing.
Web Speech API: Used to enable voice commands and text-to-speech (TTS) capabilities.

Standards like the Web Neural Network API (WebNN) are expected to greatly enhance these features through the delivery of hardware-acceleration for devices' integrated chips for artificial intelligence to web applications.

The limitations of both approaches are the following:

Performance Constraints of Browsers: Intricate or large-scale AI models can run slowly on the client-side, and even the GPU-based acceleration is quite limited compared with native applications.
Offline Use Requires Setup: Caching models for offline AI functionality requires careful implementation of service workers and storage strategies. The dependency of high-end artificial intelligence on a server requires an internet connection, which can lead to related server costs.

Built-In Accessibility (a11y) & SEO Discoverability

Inherent accessibility of PWAs represents a major strength, deriving from their base in open web standards and the large body of knowledge about web accessibility developed over the years. Native application combinations generally require separate development and accessibility testing for each separate platform (e.g., Android, iOS, desktop), whereas PWAs apply tried-and-true technology that is more accessible per se and platform-agnostic.

Frictionless User Access: Zero Friction, No App Store Walls

With respect to distribution and user accessibility, PWAs provide significant advantages over native applications:

No installation required: Users can access a PWA directly from any browser, on any device, without downloading or installing anything.
Neutralization of app store dependence: Lack of app store gatekeeping neutralizes any need for approval procedures and eliminates restrictions set through marketplace guidelines.
Immediate accessibility and revisions: Changes take effect immediately, and changes are updated at once across all user groups, ensuring improvements or changes are easily accessible.
Cross-device availability: Whether on desktop, tablet, or mobile, users can access the same application with consistent accessibility support.

WCAG & The POUR Principles: Building Truly Inclusive Apps

PWAs, in their very nature as web applications, follow the basic principles that ensure accessibility for people with disabilities, such as visual impairment, hearing disability, mobility impairment, and cognitive impairment. The major goal is to make the application perceivable, operable, understandable, and robust, in line with set standards like the Web Content Accessibility Guidelines (WCAG).

The WCAG are a widely supported standard set by the World Wide Web Consortium (W3C). The main goal is enabling websites' accessibility for disabled people with various impairment types like visual impairment, auditory impairment, physical impairment, speech impairment, or cognitive impairment without compromising the needs of other user groups like older adults, individuals with temporary restrictions, and device-diverse-interfacing users.

WCAG is built on four core principles (POUR):

Perceivable: Users can see or otherwise perceive the data being displayed.
Operable: Users can interact with the interface and navigate within it.
Understandable: Information and operation are clear and predictable.
Robust: Content works reliably across different technologies.

The guidelines below are organized along Measurable Success Criteria defined across three levels of adherence:

Level A (Minimum)
Level AA (Target and most common legal requirement)
Level AAA (Highest)

Key versions include WCAG 2.0, 2.1, and the current 2.2, with 3.0 in development. Adhering to WCAG is crucial for inclusivity, legal compliance (e.g., ADA, European Accessibility Act), improved user experience, SEO benefits, and reputation.

Google Lighthouse can also help evaluate the accessibility of the PWA, giving advice on how to correct the problems that have been encountered. Not following the Web Content Accessibility Guidelines (WCAG) can lead to legal consequences, as well as possible financial penalties.

Semantic HTML & ARIA: The Foundations of Accessible UI

Semantic HTML is the bedrock of an accessible PWA. Using correct, semantic HTML tags provides an inherent structure and meaning. Assistive technologies, such as screen readers, rely on this semantic structure to interpret the page and provide a coherent experience for the user.

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes aimed at promoting the accessibility of complex internet applications and dynamic web pages for disabled individuals relying on assistive technologies like screen reader software. It overcomes the shortcomings of traditional HTML in the communication of semantic information needed for the efficient communication of complex interactive elements like tailored tabs and carousels. It is made possible with the use of:

Roles: Defining what an element is (e.g., role="button").
States: Describing an element's current condition (e.g., aria-expanded="true").
Characteristics: Providing additional details about a specific element (e.g.
aria-label="Search").

Crucially, ARIA should only be used when native HTML elements cannot provide the necessary semantics. It ensures assistive technologies can correctly interpret and convey interactive elements, improving the user experience for everyone, especially those relying on keyboard navigation.

Other Factors to Consider:

Keyboard Focus Management: Interactive elements within a PWA should be accessible and usable only through keyboard input alone. In the Single-Page Application (SPA) design commonly used by many PWAs, developers should carefully control the user's "focus" whenever a new view is updated or a modal dialog is displayed. Focus should be programmatically changed to the newly exposed content. Otherwise, keyboard or screen reader users may be left behind on the previous screen with no awareness of any changes in the content.
Web Best Practices: Progressive Web Applications PWAs must adhere to basic accessibility standards, which involve providing proper color contrast between text and background, providing textual descriptions (alt attributes) for any important images, and using a responsive design that supports scaling of content while preserving the integrity of the important layout and key details.
OS-Level Integration: Even the PWA's manifest.json file plays a role. The name and short_name properties are what the operating system's screen reader (e.g., VoiceOver on iOS, TalkBack on Android) will announce when a user navigates to the PWA's icon on their home screen.

Accessibility Tooling: Automated Audits & Screen Readers

Most modern front-end frameworks used for PWA development (e.g., React, Vue, Angular) include built-in support or best-practice patterns for accessible components. In addition, many open-source UI libraries (e.g., Material UI, Radix UI) provide prebuilt, accessibility-compliant components out of the box.

PWAs also benefit from advanced accessibility features provided by modern browsers, such as:

Extensive compatibility with screen reader technologies (i.e., NVDA, JAWS, VoiceOver)
Settings with high contrast and little motion.
Zoom and font scaling
Keyboard and focus management

Testing accessibility in PWAs is made easier through powerful and widely used tools such as:

Accessibility evaluation using Lighthouse (bundled with Chrome DevTools).
axe-core (for automated testing).
VoiceOver, NVDA, and TalkBack (for manual testing).
ChromeLens and Accessibility Insights extension developers.

Common Pitfalls: SPAs, Focus Management & Custom Components

Requires Developer Diligence: Accessibility is not automatic. It depends entirely on developers having the knowledge and taking the conscious effort to implement it correctly.
SPA Complexity: In single-page PWAs, developers must manually manage focus and announce route changes to assistive technologies to prevent user disorientation.
Risk with Custom Components: Over-reliance on non-semantic elements (like <div>s for buttons) can easily lead to an inaccessible experience if ARIA attributes are not implemented meticulously and correctly.

Organic Reach: Built-in SEO Advantages Over Native Apps

A key distinction from native apps is that PWAs live on the web, meaning they are discoverable by search engines like Google and can be shared with a simple link. This allows for organic growth via Search Engine Optimization (SEO).

The Modern PWA Blueprint [Part 3]: Developer Velocity, Architecture & CI/CD

Alberto Boffi — Thu, 20 Aug 2026 16:53:11 +0000

Developer Velocity: Why PWAs Ship Significantly Faster

Rapid Iteration: Modern Tooling, HMR & Unified Codebases

Progressive Web App evolution draws its foundations from simplicity and speed, mainly because it also draws upon the complete set of skills surrounding web development.

The lifecycle of development follows a much faster pace compared to native apps, due to several factors:

Benefitting from Proven Frameworks and Instruments: Public frameworks like Angular or React have official and community-based templates available, which can help reduce the setup process by including essential components of a PWA by default.
Rapid Iteration and Troubleshooting: Modern build tools and libraries like Vite, Webpack, and Angular support fast build times and provide features like Hot Module Replacement (HMR), thus providing instant feedback in the browser environment. Browser development tools also provide extensive inspection and debugging capabilities specially designed for Progressive Web Applications, featuring functionalities for inspecting the manifest, tracking the lifecycle of the service worker, and allowing offline emulation.
Low Technical Entry Barrier: The first core technology barrier to market entry is that teams with HTML, CSS, and JavaScript skills do not need to be familiar with other programming languages or frameworks like Kotlin or Swift. This makes it easier to enter the market, increases the pool of talent available, and encourages the accelerated onboarding of developers.
Instant Deployment: PWAs are distributed via the internet, thus eliminating the long procedures related to compilation, packaging, and submission to app stores. Updates are deployed by simply uploading new files into a server, which makes them available instantly to users and allows for much faster iteration cycles.
Unified Codebase: One codebase can be used to support all devices running modern browsers, including Android and iOS smartphones, and desktop systems such as Windows, Mac, and Linux, thereby making it easier to develop quickly and reduce upkeep costs.

This becomes a major limitation when high-level integrated functionality, like direct Bluetooth connection and sophisticated background processing, becomes a requirement, as dependency upon browsers can add constraints or unpredictability, thereby hindering the release schedule.

Zero Back-Compat Headaches: Keeping Frontend and Backend in Sync

A very valued advantage of Progressive Web Applications to developers, in particular, is that there will be no back-compatibility issues. That means everything from new releases will be immediately available to the final client.

The main strength of this approach lies in its guarantee that any security patches or necessary functionality will be immediately applied by the receiving end user.

The second major advantage relates to synchronization across the front-end and back-end systems. The addition of virtually any newly created feature requires changes to be implemented in both the front-end and back-end systems as well. The lack of necessary adjustments in either end can lead to faulty operation of the application. For native applications, this problem can be overcome by implementing several mechanisms:

The necessity to update the application to allow its continued use represents a significant barrier to assessing the overall experience of the final user.
The extremely efficient nature of the back-end lends itself to situations where changes in the front end go unimplemented, allowing the program to run smoothly and then requiring additional input from the back end. In addition, this process involves having additional logic and code that might not be considered necessary.
The approach requires preconfiguration of the front end to be compatible with previous iterations of the back end. This requires the first release to be only of the front end, thus giving users ample time to update the application prior to release of the following back end version. This strategy, however, which embeds further features and intricacies in the front end, does not guarantee all users have made requisite application upgrades, thereby injecting a probable risk of issues after release of the back end.

Clearly, no simple and straightforward solution has been created yet. Progressive Web Apps tackle this challenge at its root level. This feature represents one of the most critical, yet often overlooked, values of Progressive Web Apps and web applications in general.

Architecture & Modularity: Leveraging the Open Web Ecosystem

PWAs excel in modularity and integration, thanks to the open, component-driven nature of the modern JavaScript ecosystem. This allows for scalable architectures and rapid experimentation for projects of any size.

The possibilities of integration are vast:

npm Ecosystem: One main feature of modularity is embodied by npm (Node Package Manager), which happens to be the world's largest software registry. Developers can build applications by combining modular packages, from simple UI component libraries (like Material UI) to utilities meant to help manage state (e.g., Redux) to analytics, form validating, and internationalizing.
Framework-Intrinsic Modularity: User interface frameworks like Angular, React, or Vue necessarily organize applications in terms of independent and reusable components. This property fits nicely within a modular paradigm, ensuring a clear split of responsibilities.
Fluent API and Service Integration: Progressive Web Apps can integrate easily with different third-party services using standard protocols like REST, GraphQL, or WebSockets. They can further integrate themselves into major platforms like Firebase, Stripe, or Auth0 using their respective JavaScript Software Development Kits (SDKs). Developers can now enjoy near-native functionality by leveraging strong JavaScript APIs like WebAssembly (for performance-critical code), WebRTC (for real-time communication), or IndexedDB (for complex client-side data storage).
Service Worker's Modularity: Service workers are defined by their modular, extensible architecture. Google suggests libraries like Workbox, which consists of a set of reusable modules aiming to abstract and simplify complex functionalities dealing with caching, routing, and background synchronization.

However, a number of issues arise:

The requirement for careful dependency management to keep packages up to date.
Ensuring libraries and APIs' interoperability within multiple web browsers and execution environments. The wide range of tools available can periodically lead to fragmentation or so-called "decision fatigue".

Automated Testing & CI/CD Pipelines for PWAs

Progressive Web App development environment is furthered by a thorough set of modern web codes analysis and testing tools, a significant portion of which have a deep heritage, solid usage, and significant flexibility.

Automated Testing: From Unit Tests to Lighthouse Audits

A solid testing strategy for a PWA can rely on a mature and well-established set of tools:

Unit Testing: Libraries like Jest, Mocha, and Vitest are utilized for testing individual JavaScript functions.
Component and Integration Testing: Tools like Testing Library (for React, Vue, etc.) and Cypress are ideal for testing UI components in isolation and their interactions.
End-to-End (E2E) Testing: Playwright, Selenium WebDriver, and TestCafe all make it possible to automate actual web browsers to mimic extensive user interactions.
Performance and PWA Audits: Google Lighthouse is the standard for auditing performance, accessibility, and PWA-specific criteria like installability and offline support.

These tools can simulate offline conditions, verify service worker behavior, test installation flows, and measure responsiveness, crucial for ensuring a PWA behaves reliably.

Static Code Analysis: Type Safety, Linting & Security

PWAs benefit from a robust JavaScript and TypeScript ecosystem for static analysis:

Linters and Formatters: ESLint for code linting and rule enforcement, typically paired with Prettier for consistent formatting.
Type Verification: TypeScript provides static type safety, which detects a broad class of errors before run time.
Security and maintainability analysis: A thorough analysis can be performed using tools like SonarQube or CodeQL created by GitHub to flag potential security vulnerabilities and issues regarding maintainability.

These tools are easily integrated into CI/CD pipelines (e.g., GitHub Actions, GitLab CI), ensuring continuous quality assurance.

Community & Open Standards: The Longevity Advantage

One of the biggest benefits of PWAs is that they enjoy community support. PWAs are part of the larger web development community, which is the largest, most mature, and most active community in the software world.

The World Wide Web Consortium (W3C) is the principal international organization that deals with Web standard setting. It was established by Tim Berners-Lee in 1994, and its mission is to ensure the long-term growth and interoperability of the Web.

These standards are the foundations for technologies like HTML, CSS, XML, and accessibility guidelines (WCAG). The standards are crucial to:

Interoperability: Enabling web content to work on different browsers and devices.
Accessibility: Making the Web accessible to all, including people with disabilities.
Evolvability: Allowing the Web to adapt without sacrificing existing content.
Openness: Preventing single-company control of foundation web technologies.

Standards are authored by a consensus-oriented, collaborative process involving its global member organizations, staff, and the public.

Further, the support landscape is wide-ranging and encompasses numerous channels:

Authoritative Documentation: MDN Web Docs (Mozilla) and web.dev (Google) provide comprehensive, in-depth, and current guidance, tutorials, and best practices.
GitHub: Endless library of open-source tools, libraries, and frameworks (e.g., Workbox for service workers, Vite, Next.js), and end-to-end PWA examples.
Package Registries: The npm registry is the largest software registry globally and provides immediate access to millions of reusable code packages for any conceivable functionality.
Developer Forums: Stack Overflow has millions of questions and answers in web-related tags (e.g., progressive web apps, service-worker, javascript). Millions of other forums, newsletters, and subreddits (e.g., r/webdev) provide daily activity.
Conferences and Events: Major events like Google I/O and Chrome Dev Summit tend to have PWA-focused content and announcements.

Since PWAs are based on open standards, they are supported by major browser vendors (Google, Mozilla, Microsoft, and Apple) and stay up to date with new specs. The community also engages regularly in browser APIs, tooling, and best practices.

The main cons, though, are:

The sheer number of choices (frameworks, tooling, libraries) itself can lead to decision paralysis and fragmentation of toolchains.
Even with browser compatibility being so much improved nowadays, occasionally developers must still account for tiny discrepancies or back-end feature support, particularly between leading browser engines (e.g., WebKit on iOS vs. Chromium).
The JavaScript ecosystem's high pace can lead to orphaned packages or the need to handle compatibility carefully between dependencies.

The Modern PWA Blueprint [Part 2]: Performance, Hardware Access & Project Fugu

Alberto Boffi — Thu, 20 Aug 2026 16:51:52 +0000

Performance in Practice: Speed, Caching & Resource Efficiency

Real-World Execution: Loading, Runtime & UI Smoothness

Unlike compiled frameworks, PWAs execute within the browser environment, and therefore their performance will be as good as the browser engine (e.g., Chromium or WebKit) and hardware available on the device.

Existing browser engines offer high-performance JavaScript execution along with hardware-accelerated rendering that enable responsive and smooth user interfaces, especially for contemporary devices.

Key performance factors influencing PWAs are:

Loading Performance & Service Workers: One of their strong points is loading performance, particularly on return visits. Service workers are JavaScript scripts that run in the background, without reference to the web page. They allow for advanced caching mechanisms like pre-caching of app assets (HTML, CSS, JavaScript, images, API responses). This allows resources to be served directly from the cache, providing lightning-fast loading times and reliable offline access.
Installation Performance: PWAs install instantly over HTTPS directly in the browser, zero app store latency, and substantial first time downloads. The storage footprints is also tremendously low (download on-demand), hence also the download time is negligible.
Runtime Performance: Depending on good JavaScript, UI complexity, and browser rendering. Libraries like React, Angular, and Vue.js provide performance utilities for UIs (e.g., virtual DOM or incremental DOM). Browsers like Google Chrome provide strong mechanisms for sustaining smooth runtime performances.
Responsiveness and Smoothness: Achieved through CSS animations/transitions, which are typically hardware-accelerated, providing best performances.

Some drawbacks:

Although, thanks to modern browser technology, the performance of a PWA is practically indistinguishably similar to that of a native app for most apps available for purchase, they won't necessarily match raw performance of completely native or compiled applications for graphically intensive applications like real-time 3D gaming or where tight, low-level hardware integration or deep background processing is required.
The UI smoothness is ensured through hardware-accelerated CSS transitions and rules. Native applications use the operating system's API and OS directly for gestures and animations. In PWAs, UI changes are routed through the browser's rendering engine to be forwarded to the operating system, resulting in overhead. This results in very little touch and animation latency and less control over performance, though slight, which under certain conditions becomes noticeable by the user.

To monitor and optimize performances, Google Chrome offers Google's Lighthouse tool, in which developers can audit PWAs, identify performance bottlenecks, and check compliance with performance best practices, accessibility guidelines, and PWA checklist requirements.

Memory Footprint & Storage: The Download-on-Demand Advantage

Apart from time, the most valuable asset of PWAs is space used. Because of the "download on demand" capability, PWAs are much smaller than native applications. This saves valuable device storage space, leading to faster loading times, improved user experience, reduced burden on user data and device resources.

Hardware & OS Access: Bridging the Native Capabilities Gap

When it comes to Progressive Web Apps, the ability to access the operating system is one of the most frequently asked questions. Unlike native apps, where the app directly interfaces with the operating system, which in turn interfaces with the hardware, here we have an additional layer represented by the browser.

Rendering Engines: The Chromium vs. WebKit Landscape

One thing worth clarifying upfront is the distinction between browsers. Actually, in this sense, it makes less sense to speak of "browser" rather than rendering engine, and, therefore, operating system.

On Android, browsers use Chromium (developed by Google) as their rendering engine, while on iOS they use WebKit (created by Apple). Chromium is the rendering engine that offers greater support for PWAs, which makes Android the perfect operating system for PWAs. Conversely, WebKit is more limiting, so much so that it restricts even Google Chrome on the iOS operating system.

This situation seems to be partially resolvable in the European Union thanks to the EU Data Act, a regulation designed to foster a more competitive data market in Europe. This regulation could impact Apple by preventing it from limiting the capabilities of external browsers, effectively allowing Google to build its browser on the Chromium engine even on Apple devices.

Web APIs: Direct Communication with Device Hardware

Since web apps have an additional step before accessing the operating system, a method is needed for the app to communicate with the browser to indicate which OS resources, and therefore hardware, it requires. This method is provided by Web APIs. Web APIs can extend browser functionalities in many ways, accessing Bluetooth, the filesystem, Battery Status, and much more. Some are now supported by all browsers, such as those for camera access (Media Capture and Streams API) or those for file system access (File System API), while others are newly developed and in the early stages, such as those for NFC usage (NFC API).

What we cannot do is list all existing Web APIs, nor how much they are supported by browsers on various operating systems. This is because they are rapidly expanding and are ensuring a prosperous future for PWAs. For a reference, the best documentation to consult is Mozilla's: https://developer.mozilla.org/en-US/docs/Web/API.

Ecosystem Maturity & The Future of Web Capabilities

Progressive Web Applications are not limited to a particular framework; instead, they are built on open web standards set by entities like W3C and supported by browser vendors like Google, Mozilla, Apple, and Microsoft. This feature makes PWAs one of the most cutting-edge and secure technologies within application development.

The underlying technologies of HTML, CSS, and JavaScript have been used for a long time. Progressive Web Applications were officially sanctioned in the mid-2010s and subsequently adopted by leading brands like Twitter, Starbucks, Pinterest, and Uber for both desktop and mobile usage. This ecosystem has proven stable and has been thoroughly tested, especially with regards to key pieces like service workers and web app manifests, which have received widespread backing on multiple web browsers. Moreover, libraries and tools like Workbox, Lighthouse, and PWA Builder remain actively supported and developed by major stakeholders in the industry.

Pros:

Backed by open standards and major industry players, ensuring longevity.
Based on strong and cutting-edge underlying technologies.
A clear roadmap for expanded capabilities via new browser APIs.

Challenges:

Variability in feature support across browsers, especially on iOS where some features have historically lagged.
A fragmented tooling ecosystem may affect consistency compared to a single-framework approach.

The future of PWAs is intrinsically tied to the evolution of the web platform itself, which is advancing rapidly. Here are some examples of innovation drivers:

Project Fugu: Closing the Native OS Capabilities Gap

A key driver is the Web Capabilities initiative (codenamed Project Fugu), a Google-led effort to close the capability gap between native and web by providing secure access to features like the File System Access API, Web Bluetooth, and advanced hardware integration.

Google's underlying principle is to extend the ability of the web by utilizing innovative web APIs, which allow web programs to access hardware and functionality heretofore reserved to native programs.

WebAssembly (Wasm): Near-Native Performance in the Browser

WebAssembly, or Wasm, is an open-standard framework of web technologies to run programs written in a variety of programming languages other than JavaScript, like C, C++, and Rust, in web environments. It defines an optimized binary format and its respective text format, aiming to provide performance similar to native execution of machine code. Initially proposed to improve elemental parts of web application components, WebAssembly has transformed to allow developing and running web applications based on a variety of programming languages, thereby extending its purpose beyond just supporting JavaScript. Development of this technology happens within the auspices of World Wide Web Consortium (W3C) and opens itself to contributions from many organizations, including Mozilla, Microsoft, Google, and Apple.
The increasing maturity of WebAssembly allows more performance-intensive applications to run efficiently in the browser, significantly expanding the scope of what PWAs can achieve.

Hybrid Distribution: Packaging PWAs for App Stores

Trusted Web Activities, created by Google, and Capacitor, built by Ionic, allow PWAs to be packaged to different application marketplaces, such as the Google Play Store, Apple Store, and Microsoft Store, thereby offering hybrid distribution approaches.

The Modern PWA Blueprint [Part 1]: Cross-Platform Reach & UI Freedom

Alberto Boffi — Thu, 20 Aug 2026 16:51:10 +0000

Why PWAs? Bridging Web Reach and Native Power

Progressive Web Applications (PWAs) are types of web applications that utilize modern web technologies to provide an experience similar to that of native apps. These are built using universal web technologies, namely HTML, CSS, and JavaScript, but with additional functionalities typically associated with native apps, like offline capability, support for push notification, and ability to install from a device's home screen directly.

The core idea behind PWAs is to seamlessly combine the broad reach and accessibility of the web with the performance, engagement features, and app-like feel of native applications, without requiring distribution through traditional app stores.
The main advantages are the single codebase, instant dissemination and updates, no limitations placed by platform owners, no app store fees, better search engine optimization, and lower storage needs.

Despite growing excitement around PWAs, decision-makers often find themselves confused when evaluating them relative to native or hybrid offerings. While technical specs and successful pilot implementations do abound, few thorough reviews based on plainly stated Key Performance Indicators (KPIs) are available. In this article I go through PWAs across several KPIs, to give you a concrete basis for understanding their suitability in various development scenarios.

Cross-Platform Reach: Escaping the App Store Tax

Platform and device reach capabilities are perhaps the largest and most intriguing benefits of PWAs.

Unlike native or compiled cross-platform solutions, PWAs do not, by their very nature, require platform-specific distribution pathways or app store approval for their basic deployment. Updates are frictionless and instant for all, delivered directly from the web.

The benefits of this approach are the following:

Single codebase: A single codebase to cover all of the environments. In other words, a single project and a single development team, fewer development time and cost.
Instant global updates: Every update is out on every platform right away, with no user intervention required. This also reduces the issues of backwards compatibility, both across versions of the front-end application, and between front-end and back-end.
Cheating app store restrictions: Ensures that the app is available everywhere and that there is no platform owner able to prohibit publication. No approval trail, no gatekeepers, no random blocking.
No app store fees: No app store sign-up fee or commission charges.

There are, however, some disadvantages to it:

A PWA relies on a web browser, so they can't be utilized in non-browser devices like smart TV, and their support is sparsely available on unsupported Chromium browsers.
The existence and behavior of advanced PWA features may vary across browsers and operating systems.

The following is the list of supported platforms:

Mobile: Android (excellent support), iOS (good and still enhancing support).
Desktop: Windows, macOS, Linux, ChromeOS (where they support a near-native experience).
Other environments: Minor Smart TVs, wearables, and embedded systems support.

Let's now discuss the level of support and integration.

Android
Offers the most feature-rich PWA support. PWAs can be prompted to "Add to Home Screen", be accessed via the app drawer, be displayed full-screen, manage notifications, and integrate deeply with the OS.

iOS
Apple support within Safari has progressed a long way. PWAs can be installed to the home screen for a standalone, app-like experience. Caching and offline service workers are supported well. Push notifications in PWAs on iOS have existed since iOS 16.4, though feature parity with native app notifications or Android PWA notifications may still be in development.

Desktop
Large desktop browsers (most notably Chromium-based ones like Chrome and Edge, though also Safari on macOS and Firefox) support PWAs. This allows PWAs to run in their own sandboxed windows, to show taskbar/dock icons, and to behave very much like traditional desktop applications.

The Apple limitation comes from the reality that Chrome on iOS relies on the WebKit engine. Apple is affected in the European Union by the Digital Markets Act, which prohibits it from excluding competing browsers. This would allow Google to implement the Chrome browser on the Chromium engine even on Apple gadgets, with PWAs maintaining the same features as they do on Android.

UI Freedom: Total Design Control & Dynamic Theming

A Progressive Web App's potential for customization is directly related to the power and flexibility of the open web platform. Built with core web technologies (HTML, CSS, and JavaScript) PWAs give developers almost total control over the look, feel, and behavior of the app on all devices.

As opposed to platforms that may prescribe their own UI toolkit or abstract the render layer away, a PWA renders directly into the browser engine. This allows developers direct access to the Document Object Model (DOM) and pixel-perfect, fine-grained design control. This open, standards-based model allows:

Total Design Freedom: Developers aren't limited to a set of predefined components. They can create fully custom user interfaces that perfectly reflect a brand's identity, include any third-party UI library, or develop their own component ecosystems unhindered by platform constraints. Or they can take advantage of popular and highly extensible CSS frameworks like Tailwind CSS, Bootstrap, or custom SCSS to accelerate development while still maintaining the ability to override any style.
Advanced Responsive Design: PWAs excel at adapting to different form factors due to new CSS techniques like Media Queries, Flexbox, and Grid. Interfaces can be resized dynamically and automatically for any screen size, from mobile to tablet to desktop, so the experience is always ideal everywhere.
Rich Animations and Transitions: Using CSS transitions, keyframe animations, and powerful JavaScript animation libraries (e.g., GSAP, Framer Motion), it is possible to create smooth, interactive, and advanced animations that enhance the user experience and give the application a professional, polished look.
Theming and Dynamic Styles: New CSS capabilities, in particular Custom Properties (variables), have made it simple to establish robust theming systems. A developer can define a global design palette (colors, fonts, spacing) that can be applied consistently and changed dynamically, which makes "dark mode" accessibility adjustments, or user-selectable themes trivial to implement.
Deep Experience Control: Customization extends beyond the UI. The service worker, a core PWA building block, enables developers to exactly control caching mechanisms, define sophisticated offline behavior, and manage push notifications, all resulting in an extremely tailored and performant user experience that feels integral to the device.

Asymmetric Encryption & PKI: Digital Signatures, RSA, and Future Security

Alberto Boffi — Sun, 16 Aug 2026 12:09:45 +0000

Asymmetric Ciphers: Why Do We Need Something Different?

An asymmetric cipher (or public key cipher) is a cipher where the encryption and decryption keys are different.

Asymmetric ciphers were born to solve two main problems related to symmetric ciphers:

Symmetric ciphers cannot provide authenticity;
The security of a symmetric cipher is based on the precondition that the key has been previously exchanged in a secure way. But there is no way to do it, other than encrypting the key itself, which would recursively raise the same problem of exchanging another key.

The trade-off? Efficiency. Asymmetric ciphers are from 10x to 1000x slower than symmetric encryption.

In an asymmetric cipher, each one of the two endpoints has two keys, called public key and private key (or secret key), where the public key is built starting from the private key: $k_{p u b} = f (k_{p r i})$ .
As the name suggests, the public key can be visible to everyone, while the private key is only known by the respective endpoint. The cipher is based on three main features:

If the message has been encrypted with the private (public) key of a certain endpoint, it can be only decrypted with public (private) key of the same endpoint;
If the message has been encrypted with the public key, decrypt it without knowing the private key must be computationally hard;
Compute the private key given the public key (i.e. compute $f^{- 1} (k_{p u b})$ ) must be computationally hard.

To give a concrete example, a private key can be the set of two large prime numbers $p$ and $q$ , while the public key the product $p \cdot q$ . At this point, finding the prime factors that make up the public key means solving a famous NP problem known as prime factorization.

As for symmetric ciphers and cryptographic hash functions, since we cannot prove the exponential lower bound complexity of an algorithm, asymmetric ciphers are the outcome of public contests.

Confidentiality & Key Encapsulation

Asymmetric encryption can be used to provide confidentiality against a ciphertext-only attack as follows:

Bob (receiver) generates a keypair $(k_{p r i}, k_{p u b})$ . He sends $k_{p u b}$ to Alice;
Alice (sender) encrypts the plaintext with Bob's public key: $c t x = E (pt x, k_{p u b})$ . She sends it to Bob;
Bob decrypts the ciphertext using his private key: $pt x = D (c t x, k_{p r})$ .

Symmetrically, if Alice in turn generates another pair of private and public key, Bob can send messages to Alice too, producing a secure bi-directional communication.
However, since asymmetric encryption is so much slower than symmetric encryption, in practice an asymmetric cipher is never used to entirely manage a communication. Instead, it is used to do what is called key encapsulation, i.e. to securely exchange the key to use from there on with a symmetric cipher. Since the key is the only message being exchanged, just a pair $(k_{p r i}, k_{p u b})$ for only one of the two endpoints is enough. Moreover, for this reason we don't really need to consider known-plaintext attacks for asymmetric ciphers.

The standard cryptosystem used to provide confidentiality through asymmetric encryption is the Rivest-Shamir-Adleman, commonly known as RSA, which is actually based on the prime factorization problem.

Maintaining Integrity

For the property of integrity, nothing changes with respect to a symmetric cipher: we can still use a MAC tag in the same way.

Solving Authenticity: Digital Signatures

With an asymmetric cipher, we can actually provide authenticity. In this scenario, we are not interested anymore in hiding the content of the message, but in guaranteeing the identity of the sender. The way we can do it is by adopting the digital equivalent of a handwritten signature:

Alice (sender) generates a keypair $(k_{p r i}, k_{p u b})$ . She sends $k_{p u b}$ to Bob;
Alice sends the message $m s g_{A}$ in clear text to Bob;
Alice encrypts the message with her private key: $d s = E (m s g_{A}, k_{p r i})$ , where $d s$ is called digital signature. She sends the digital signature to Bob;
Bob (receiver) decrypts the digital signature with Alice's public key: $m s g_{B} = D (d s, k_{p u b})$
Bob compares $m s g_{B}$ with the message $m s g_{A}$ previously sent in clear text by Alice: if they are equal authenticity is guaranteed.

The role of the digital signature is therefore to guarantee that the endpoint who sent the message is the same one that originally transmitted the public key. This mechanism works in theory, but there's a practical problem: usually we want to provide authenticity in exchanging big documents, and when the message is particularly long the encryption is slow.
We can solve the problem by exploiting the cryptographic hash functions: Alice also sends the hash $h (m s g_{A})$ of the message, and produces the digital signature by encrypting $h (m s g_{A})$ instead of $m s g_{A}$ . At this point Bob can decrypt it and compare the result with the hash sent in clear by Alice.
Since the hash has a fixed length regardless of the size of $m s g_{A}$ , we are gaining in efficiency.

Another problem is due to the difference between digital signatures and paper signatures. In the physical world, to sign means to sign the output, while in the digital world it means to sign the code.
To understand this concept, let's imagine that we are signing a digital document. In reality, we are not signing what is written in the document at that specific moment, since the document can contain dynamic content, such as a date that changes according to the current day: when the date updates, the signature remains the same, and this is not the desired behavior.
Actually, there is no real way to solve this problem, other than signing only the types of document that can't change.

As last observation, let's imagine we want to provide confidentiality together with authenticity. In this case, we can combine the mechanisms seen for both properties, in a "matrioska" structure.
We are not going to see this in an explicit way, but in general both Alice and Bob will generate their own $(k_{p r i}, k_{p u b})$ pair. Then, Alice will first encrypt the message using her private key, and then she will encrypt the result another time with Bob's public key. Bob will decrypt the ciphertext received with his private key first, and then with Alice's public key.

The RSA standard, other than confidentiality, is built to provide authenticity as well.

How Secure Are They Compared to Symmetric Ciphers?

We have seen that the only possible attack to a secure symmetric cipher is brute-forcing the key, which has a cost of $T (λ) = O (2^{λ})$ .
Asymmetric ciphers, instead, rely on hard problems for which brute-forcing is not the best attack. This implies that break a secure asymmetric cipher requires little less than $O (2^{λ})$ operations, depending on the particular algorithm employed. Thus:

It's not possible to rely on the length of the key to compare the security of an asymmetric cipher with the security of a symmetric cipher.

We can only use the length of the key to compare two symmetric ciphers. If, instead, we want to compare the security of an asymmetric cipher, we need to know the computational complexity needed to break it.

Public Key Infrastructure

We're not done yet. For the moment, we cannot yet guarantee the full security of an asymmetric cipher. In fact, the asymmetric cipher architecture presented so far is sensitive to another kind of attack, called Man In The Middle (MITM) attack. In a MITM attack, the attacker can intercept any message exchanged between Alice and Bob, and send messages in turn. For this reason, he can be (logically) seen as a "man in the middle" of the communication.
A MITM attack can pose a threat to the communication since we have not yet seen a way to "bind" the public key to the endpoint that produced it. To understand this, let us suppose that Alice wants to send her public key $k_{p u b (A)}$ to Bob. If the attacker generates his keypair $(k_{p r i (E)}, k_{p u b (E)})$ , he can intercept $k_{p u b (A)}$ and send $k_{p u b (E)}$ to Bob instead. At this point, Bob will treat $k_{p u b (E)}$ believing it to be Alice's key. The attacker can now use his private key $k_{p r i (E)}$ to decrypt the messages sent by Bob, violating the confidentiality constraint, and to sign messages towards Bob, violating the authenticity constraint. He can furthermore carry on the communication in both directions, talking to Alice pretending to be Bob, and to Bob pretending to be Alice.

To prevent a MITM attack, we need to apply the same mechanism we just saw for providing authenticity on the message, but now providing authenticity on the public key that Alice sends to Bob. To do that, we introduce a new endpoint, called Certificate Authority (CA).
The communication consists of two phases. In the first phase, Alice communicates with the Certificate Authority:

Alice generates a keypair $(k_{p r i (A)}, k_{p u b (A)})$ . She sends $k_{p u b (A)}$ to the CA;
The CA generates a keypair $(k_{p r i (C)}, k_{p u b (C)})$ . It signs Alice's public key: $d s = E (k_{p u b (A)}, k_{p r i (C)})$ ;
The CA sends to Alice a collection of data containing: the digital signature $d s$ , the subject's public key $k_{p u b (A)}$ , the CA public key $k_{p u b (C)}$ and other details, as the signature algorithm or information about Alice. This collection is called digital certificate;

The second phase involves the communication between Alice and Bob. Now, we assume that Bob has a list of public keys owned by CAs he trust:

Alice sends the digital certificate to Bob;
Bob verifies that $k_{p u b (C)}$ is in his list of trusted public keys. If not, he discards the digital certificate;
If $k_{p u b (C)}$ is trusted, Bob decrypts the digital signature $d s$ with $k_{p u b (C)}$ : $k = D (d s, k_{p u b (C)})$ ;
Bob compares $k$ with $k_{p u b (A)}$ : if they are equal, authenticity on Alice's public key is guaranteed.

This communication scheme as it stands works in theory, but in practice there exists a large number of Certificate Authorities, and Bob can only have a small number of them in his list of trusted public keys. So, whenever he receives a public key from a new legitimate CA, he will discard the digital certificate. We therefore need to reduce the number of CAs to trust.
To do this, the key $k_{p u b (C)}$ of the CA is in turn authenticated by another higher-level CA, responsible for signing multiple low-level CA's public keys. For the same reason, the public keys of the high-level CAs are signed by other CAs on a higher level, and so on. The top-level CAs are called Root CAs: they are the only CAs that self-sign their certificates, and therefore the only CAs we need to trust.

All this mechanism of creation and distribution of digital certificates is known as Public Key Infrastructure (PKI).

What's Still Unsolved?

Despite everything we've covered, there are still some open problems in cryptography. Among these we can mention:

Homomorphic encryption: Homomorphic encryption is a form on encryption that allows users to perform computation over encrypted data without decrypting it. It's pretty useful when the user wants to give this data to a third-party as a public cloud infrastructure. We are already able to do it, but in the state-of-the-art the process it's quite slow. The challenge is to find more efficient ways to do it;
Quantum computing: Several NP problems underlying cryptographic algorithms, such as the prime numbers factorization, can be actually quickly solved by quantum computers. Nowadays there exists a research field, called post-quantum cryptography, that studies algorithms that are difficult to solve even for a quantum computer;
Side-channel information: Another, different kind of attack that can compromise a secure communication, is the side-channel attack. In a side-channel attack, instead of exploiting vulnerabilities in the cipher, the attacker exploits extra information derived from the implementation of the cipher, as power consumption or electromagnetic radiations emitted by the encryption device. The prevention of side-channel attacks is still a much debated and studied topic.

If you've made it this far, you now have a solid foundation to understand how modern cryptography works under the hood: from perfect ciphers that are beautiful in theory but impractical, to the block ciphers and hash functions that actually protect your data every single day. Which of these topics are you most curious to explore further?

Beyond Secrecy: Data Integrity, Cryptographic Hashes, and HMAC

Alberto Boffi — Sun, 16 Aug 2026 12:09:16 +0000

Beyond Secrecy: How We Guarantee Data Integrity in Symmetric Ciphers

We move now from confidentiality to the constraint of integrity. This might seem counterintuitive when talking about cryptography, but now we are not interested anymore in hiding the message to transmit, but just in guaranteeing that the content of the message can't be manipulated along the channel.
As we did for confidentiality, we need to model the attack framework that we assume is in place. In this case, we consider a bit-flipping attack (or active attack), in which the attacker can intercept and tamper with the data.
To understand the danger of this kind of attack, try to imagine a bank transaction: by simply changing some bits in the ciphertext, once decrypted, the message can contain a different amount of money with respect to what was originally sent.

Basic Idea: To provide integrity, we can append to the message a tag that the attacker is not able to forge, which can guarantee that the message has not been tampered with. This tag is also called Message Authentication Code (MAC) (and by the way, please note that the name is misleading: the Message Authentication Code provides integrity, not authenticity).
From a high level perspective, we can see this idea as a set of two functions, the first one used by the sender, and the second one by the receiver:

$co m p u t e_{M A C} (s t r in g, k ey) = t a g$
$v er i f y_{M A C} (s t r in g, t a g, k ey) = {t r u e ∣ f a l se}$

In practice, we can implement this concept using different approaches. CBC-MAC The idea behind a CBC-MAC basically consists in using as tag an encrypted version of the message. But since now, as we will see, the tag will not be decrypted by the receiver, we can use the block ciphers in a different way with respect to the CTR mode, in order to produce a shorter output string.
In particular, the block ciphers are connected in cascade in such a way that the input of each one is the output of the previous block XORed with the corresponding section of the message (the first section can be simply XORed with a 0).
In case the message has a fixed prefix, the tag has to be encrypted one more time for the technique to be secure.

At this point, we can describe the communication flow as follows:

Alice, given the message $m s g$ and the key $k$ , calculates the CBC-MAC tag and sends it to Bob together with $m s g$ ;
Bob, using the message received by Alice and the key $k$ , calculates the CBC-MAC from his side;
Bob compares his CBC-MAC with the one sent by Alice. If they are the same, the message has not been tampered with.

This method works since any attempt from the attacker to forge the message would cause a change even in the CBC-MAC calculated by Bob. To forge the message, the attacker should also change the CBC-MAC accordingly, but he cannot do it without the key.

The problem with this technique is the efficiency: calculating the CBC-MAC tag every time a message is sent is expensive and slow. This is where things get interesting: enter the next method. Cryptographic Hash Functions

A Cryptographic Hash is a function $H : Σ^{*} \to Σ^{n}$ for which the following problems are computationally hard:

Resistance to first preimage attack: Given $d = H (s)$ , find $s$ (i.e., invert $H$ ).
In the ideal case, the computation required is $T (n) = O (2^{n})$ ;
Resistance to second preimage attack: Given $s$ and $d = H (s)$ , find $r \neq = s$ such that $H (r) = d$ .
In the ideal case, the computation required is $T (n) = O (2^{n})$ ;
Resistance to collision: Find $r, s$ with $r \neq = s$ such that $H (s) = H (r)$ .
In the ideal case, the computation required is $T (n) = O (2^{\frac{n}{2}})$ .

The output of the function is called hash or digest.

Working with bits, in our case a cryptographic hash function can be more explicitly defined as $H : {0, 1}^{*} \to {0, 1}^{n}$ . So what it does is taking an arbitrary-length-input and convert it into a fixed-length-output. This means that the function is not injective: there will necessarily be multiple input being mapped into the same output. It's however not possible to compress the input indefinitely, as there always exists a minimum number of bits, called entropy, that can be used to represent a certain information. But not every function of this kind is a cryptographic hash function, as they must respect the three requirements. For example, a simple function that just takes the first $n$ bits of the input string is not resistant to both second preimage attack and collision.

The second preimage attack can be reduced to the first preimage attack, and this means that if $H$ does not satisfy the first property, it will necessarily not satisfy the second too. The opposite is, in general, not true. This also explains why, in the ideal case, the time complexity of the two attacks is the same. The ideal complexity required to find a collision is less because the computation can be speeded up by exploiting the math behind the probabilistic birthday paradox.

Worth noting: the first two properties are what, commonly speaking, distinguishes a cryptographic hash function from a simple hash function, which just tries to avoid conflicts.

As discussed talking about block ciphers, we cannot prove in theory that a function is a cryptographic hash function, since we cannot prove the exponential lower bound complexity of an algorithm. So, even in this case, these functions are the result of public contests.
Old cryptographic hash functions as SHA-1 and MD5 has proven to be broken. Nowadays, we can confidently use SHA-2 and SHA-3, that can produce digests of 256, 384 or 512 bits. SHA-3 has been produced because SHA-2 actually shares some mechanism with functions that have been proven to be broken, but both SHA-2 and SHA-3 are currently unbroken and widely standardized. Cryptographic hash functions are highly employed in computer security, for example to avoid storing passwords and other important data in clear text, or in digital forensics to obtain a "fingerprint" of the acquired disk. For our purposes, we need cryptographic hash functions to compute a MAC tag that is easy to build and verify.
Contrary to what we have done for the CBC-MAC, now Alice cannot simply use $h (m s g)$ as MAC tag to send with the message $m s g$ , since it would be completely useless. In fact, given that the hash is produced without using a key, the attacker can simply forge the message and change the tag accordingly.
So, given the key $k$ that Alice and Bob are using, the problem can be solved by using $h (m s g + k)$ as a tag.
We can therefore provide a tag that can guarantee integrity, and that can be computed much more efficiently with respect to the CBC-MAC.

It's worth pointing out that this is just the general idea behind how cryptographic hash functions are used to ensure integrity. In reality, the mechanism is more complex and sophisticated, and goes by the name of HMAC.

The Authenticity Constraint: Why Symmetric Ciphers Are Not Enough

Before moving on to the next part, let's briefly consider the scenario where we want to provide authenticity. This means that the attacker is communicating with the receiver by pretending to be someone else. Differently from confidentiality and integrity, there is actually no ongoing attack to model here: we're just considering standard communication, with the only difference being that the receiver was expecting a message from another sender.

Unfortunately, a symmetric cipher cannot be used to provide authenticity, so we can't discuss this property. To break through, we need a fundamentally different idea, called asymmetric cryptography, that will be discussed in the next article.

Symmetric Encryption: From One-Time Pad to AES and Block Ciphers

Alberto Boffi — Sun, 16 Aug 2026 12:08:55 +0000

Symmetric Ciphers: The Fight for Confidentiality

Let's start with the simpler of the two families. As previously discussed, a symmetric cipher is a cipher in which the required encryption and decryption keys are the same.

The first constraint we will analyze is also the most popular and discussed when talking about cryptography: confidentiality.
To be able to correctly judge the level of confidentiality of our cipher, the first thing to do is to put ourselves inside a framework where we assume to be under some kind of attack. In particular, we'll consider the most basic model of an attack, called ciphertext-only attack. In a ciphertext-only attack, the attacker can simply intercept and read the ciphertext transmitted over the channel.

The Perfect Cipher

Let $c t x_{se n t}$ be the ciphertext transmitted over the channel, and $pt x_{se n t}$ the corresponding plaintext. A cipher is said to be perfect iff $\forall pt x \in P$ and $\forall c t x \in C$ we have $P (pt x_{se n t} = pt x) = P (pt x_{se n t} = pt x ∣ c t x_{se n t} = c t x)$ .

In other terms, after eavesdropping the communication, the attacker has not any additional information with respect to what he previously knew. But this definition is not constructive. If a perfect cipher actually exists, how we can build one? Let's first look at a characteristic feature of a perfect cipher:

If a cipher with $∣ P ∣ = ∣ C ∣$ is perfect, then $∣ K ∣ \geq ∣ P ∣$ .

Let me walk through the intuition behind this theorem.
We are considering the case where the number of plaintexts is the same as the number of ciphertexts: for instance, suppose $P = {pt x_{1}, pt x_{2}, pt x_{3}}$ and $C = {c t x_{1}, c t x_{2}, c t x_{3}}$ .
If the number of keys is enough, we can theoretically map every plaintext in each possible ciphertext, depending on the key used. If instead the number of keys is not enough, some ciphertexts will not be mapped by every possible plaintext. This means that every time one of these ciphertexts is transmitted, the attacker will get more information than he had before. To understand it better, let's continue with the same example, and suppose that the key space has only two keys: $K = {k_{1}, k_{2}}$ . We can define a possible encryption function as follow: $E (pt x_{1}, k_{1}) = c t x_{1}$ , $E (pt x_{1}, k_{2}) = c t x_{2}$ , $E (pt x_{2}, k_{1}) = c t x_{2}$ , $E (pt x_{2}, k_{2}) = c t x_{3}$ , $E (pt x_{3}, k_{1}) = c t x_{2}$ , $E (pt x_{3}, k_{2}) = c t x_{3}$ .

Remember that this mapping is known to the attacker: as we discussed earlier, the cryptosystem is fully known to him.
For the sake of simplicity, let's just focus on $pt x_{1}$ , but the same reasoning can be applied to each plaintext: before the transmission the attacker can state that $P (pt x_{se n t} = pt x_{1}) = P (pt x_{se n t} = pt x_{2}) = P (pt x_{se n t} = pt x_{3}) = \frac{1}{3}$ , as he has no idea which message will be transmitted. Let's now suppose that $c t x_{3}$ is transmitted other the channel. At this point, since there is no key mapping $pt x_{1}$ to $c t x_{3}$ , the attacker knows that $pt x_{se n t} \neq = pt x_{1}$ . He can consequently tell that $P (pt x_{se n t} = pt x_{1} ∣ c t x_{se n t} = c t x_{3}) = 0 \neq = P (pt x_{se n t} = pt x_{1})$ . Therefore, we can state that the cipher is not perfect. Moreover, we can observe that the hypothesis of the theorem about $∣ P ∣ = ∣ C ∣$ is not so far-fetched: intuitively, in the encryption, to be sure that the same key does not map multiple plaintexts in the same ciphertext, we need at least as many ciphertexts as the number of plaintexts, i.e. $∣ P ∣ \leq ∣ C ∣$ . In the decryption we can apply the opposite reasoning: to be sure that the same decryption key does not map multiple ciphertexts in the same plaintext we need $∣ P ∣ \geq ∣ C ∣$ . So at the end we obtain $∣ P ∣ = ∣ C ∣$ . The only real example of secure cipher we have today is the Vernam cipher, also called one-time pad (OTP). In its most popular form, it considers $P = C = {0, 1}^{l}, K = {0, 1}^{λ}$ . The encryption function $E$ performs a bitwise XOR between the plaintext and the key to obtain the ciphertext. The decryption function $D$ is exactly the same function as $E$ : by performing a bitwise XOR between the ciphertext and the key, it returns the original plaintext. The key is called "pad". More formally:

E (pt x, k) = pt x \oplus k, D (c t x, k) = c t x \oplus k

However, keep in mind that this is not the only possible implementation of a OTP cipher. Another, conceptually equivalent variant, is the one in which the encryption function performs a modulo

l

addition between each character of the plaintext and the corresponding character of the key. In other terms, it works on the additive group

Z_{l}

. The robustness of OTP is due to some strict assumptions:

The pad must have at least the same length $l$ as the plaintext;
The pad must be chosen randomly, i.e. it must be uniformly distributed in the set of all possible keys;
The pad must never be reused (hence the name one-time pad).

About point 3, the best way to understand the danger of key-reusing is by seeing it in action. Suppose we want to use the OTP cipher on images, and we encrypt the dog image with a certain key:

Let's now encrypt another image (the cat image) with the same key:

The two results, taken individually, appear pretty random. But when we XOR them together, we get the XOR of the two original plaintexts, and this is what it looks like:

It's therefore evident that the attacker can get information about every plaintext that has been encrypted with the same key.
To test it yourself: https://t.ly/7YJX.

If these three assumptions are met, there is no way an attacker can get information about the plaintext by observing the ciphertext. The only information he could infer is the length of the plaintext (since it is the same of the length of the ciphertext), but this is already a public information of the cryptosystem. We can therefore state:

OTP is not vulnerable to brute force attacks.

In fact, by brute forcing all the possible keys, an attacker would get all the possible plaintexts, but the plaintext space is an information he already had before. This cipher is still used in government scope, but, unfortunately, for our everyday purposes is impractical. The reasons why actually lie in the assumptions stated before:

The first problem is to communicate the key to the receiver in a secure way, and in the case of OTP this means to communicate a message at least as long as the plaintext. The advantage in communicating the key, instead of directly communicate the plaintext, is that in this way we can send a unique long bitstream that can be used to extract multiple keys, until the sum of the length of the messages to sent reaches the length of the bitstream. But this process makes the data to communicate even bigger. Nowadays, where OTP is used, the key is communicated in person, even if this is still a method sensitive to corruption or theft. But this is obviously not an option for our daily purposes;
Generating a key that is completely random is not an easy task at all. True-random generators exist, but they are harder to implement and slower than pseudorandom generators;
We need as many keys as the possible messages that can be sent from here on, theoretically forever. In practical applications, some key reuse problems have arisen.

Since building a OTP cipher is not practical, we have to leave the ambition of a perfectly secure cipher. The idea is to go towards something more feasible to implement, that, even if not perfect in theory, is unbreakable in practice. And honestly, that's good enough.

Computationally-Secure Cipher: Good Enough Is Good Enough

We have seen that, in a perfect cipher, the attacker cannot know the plaintext associated to a ciphertext without knowing the key. But what if the plaintext can be actually obtained, yet the process of doing this is extremely computationally difficult?

A secure cipher is a cipher that is computational hard to break.

The statement refers to NP problems and it is telling that, in order for a cipher to be secure, decrypting the message without knowing the key should be reduced to solving a NP problem.
Note that this concept is based on the non-proved assumption that $P \neq = NP$ . If one day it will be proved that $P = NP$ , every concept described from now on will immediately collapse, and modern cryptography will have to be entirely thrown away. Let that sink in for a moment.
But how we can use this definition to our advantage?
We have seen that the problems with the implementation of a perfect cipher derive from the generation and distribution of long keys. We can therefore think to manage a communication as follows:
Basic Idea: Alice and Bob exchange a key that is shorter than the plaintext. At this point, both Alice and Bob use the same deterministic function to extend the length of key, in order to reach the length of the plaintext. With the same key, Alice and Bob can now communicate using a OTP protocol.
The function used to stretch the key goes under a particular name in the literature:

A Pseudorandom Number Generator (PRNG) is a deterministic function $PRNG : {0, 1}^{λ} \to {0, 1}^{λ + n}$ , where $n$ is called PRNG stretch.

The problem now is that, since the exchanged key is shorter than the plaintext, the cipher isn't perfect anymore. However, if the PRNG is hard to break, using Proposition 2 we can say that the cipher is by definition secure. In particular, still denoting with $λ$ the length of the original exchanged key, and assuming that the attacker can only do computations with polynomial complexity with respect to $λ$ :

A Cryptographically Safe Pseudorandom Number Generator (CSPRNG) is a PRNG whose output cannot be distinguished from an uniform random sampling of ${0, 1}^{λ + n}$ in $O (p o l y (λ))$ .

Although possible, building and testing a CSPRNG from scratch is neither efficient nor practical. So the real question becomes: how do we practically implement it? Actually, a CSPRNG is built by means of a particular building block, called block cipher. Let's first define and analyze a block cipher, then we'll move to describing how it is used to build a CSPRNG.

A block cipher is an encryption algorithm that takes as input a key $k$ and a string $pt x$ of a fixed length $b$ (called block), and returns an output of the same length. Given $k$ , the encryption function $E (pt x, k)$ corresponds to one of the possible permutations over the set of the $2^{b}$ possible input blocks.

When dealing with cryptography through a theoretical lens, a block cipher usually goes under the name of Pseudorandom Permutation (PRP), but both terms mean exactly the same thing.

A block cipher that accepts keys of length $λ$ is said to be broken if, without knowing the key, the plaintext can be derived from the ciphertext with less than $2^{λ}$ operations.

This means that in an unbroken block cipher the only way to derive the plaintext is to brute force the key, which costs $T (λ) = O (2^{λ})$ .
There are some examples of widespread block ciphers. In the 1970s the standard was the Data Encryption Algorithm (DEA, aka DES), but the keys were only long 56 bits, and nowadays it can be broken in a reasonable amount of time. A variant is Triple DES, that we can superficially see as the same algorithm but with a three-times recursive encryption. Triple DES can still be found in some legacy systems, but it's officially deprecated. The standard algorithm is now Advanced Encryption Standard (AES). In AES, the block has a length of 128 bits, and the key can be 128, 192 or 256 bits long.
Keep in mind that the time required to brute-force a cipher that uses a 256-bits key is not even astronomically quantifiable, and also a 128-bits length can be considered more than enough. Obviously, it's rare that the message we want to encrypt is exactly of the same length of the block. In particular, the case where $l e n (pl ain t e x t) < l e n (b l oc k)$ doesn't cause any problem, since it's sufficient to extend the plaintext with a sequence of fixed bits ("padding"), until we reach the length of the block.
But what most of the time happens is that $l e n (pl ain t e x t) > l e n (b l oc k)$ , and so the block cipher is always used in conjunction with some mechanism to overcome this problem, that comes under different names:

Electronic CodeBook (ECB)

It's the most intuitive method, and it's based on the principle of split-and-encrypt: we split the plaintext in multiple segments and we encrypt each segment with the same key.

It's fast, easy to implement and even suitable for parallelization. The decryption is straight forward as well. The problem arises when in the original message there are repetitions, and two or more blocks come out to be the same: in this case, even the corresponding outputs will coincide. Therefore, even if the attacker does not know the corresponding plaintext, he knows that such parts are repeated, and that's a huge and really dangerous information. This is usually shown with the "ECB penguin" example: the one on the left is the original image, while on the right its encrypted version computed in ECB mode. Due to lot of repeated sections in the original image, the result it's pretty bad in terms of confidentiality:

Counter (CTR) Mode

To overcome the drawback of the Electronic CodeBook, this time we use a counter, made of numbers of fixed length, sequentially increased. We encrypt each value of the counter and then we XOR it with each segment of the plaintext. This process will return an output that it's always different.The starting number of the counter is indifferent, and we can also decide to use an increment different than 1, but 1 is secure enough and results in a more efficient computation.

We can also repeat the experiment of the encryption of the penguin image, using now the CTR mode. The difference in the result is pretty evident:

The CTR mode is actually the definitive implementation of our original idea about the construction of a computationally-secure cipher. In fact, in its schema we can actually spot a PRNG (highlighted in the figure below), that stretches the key received as input. If the block ciphers are not broken, the PRNG is also a CSPRNG. The concatenation of the outputs of each block cipher is the output string of the CSPRNG, which is then XORed with the plaintext in order to obtain the ciphertext, as in the OTP cipher.

How Block Ciphers Are Actually Built

I won't cover the algorithms behind the commonly used block ciphers here, but it is important to discuss the process that leads to their creation.
As we have seen, to prove that a PRNG is a CSPRNG we should prove that the block cipher employed is not broken, i.e. that deriving the plaintext or the key has at least a cost $T (λ) = O (2^{λ})$ . However, unfortunately, we are not (yet) able to do this. In fact, proving the exponential lower bound complexity of an algorithm would imply proving that $P \neq = NP$ . The only thing we can do is to prove that a PRNG is not a CSPRNG, in case we are able to derive the plaintext with less than $2^{λ}$ operations.
For this reason, the commonly used block ciphers are the result of public contests, where cryptographers propose their algorithms and other cryptographers try to break them.
At the beginning, introducing cryptography, we said that a public cryptosystem must not compromise security. We see now that a public cryptosystem actually improves security, since it means more revision, more testing and so more guarantees of robustness. This is something I find really elegant about the field.

What If the Attacker Already Knows Part of the Message?

So far we have analyzed confidentiality under the hypothesis of a ciphertext-only attack. But a ciphertext-only attack is not the only kind of attack that can compromise the constraint of confidentiality. Another possible threat is the so-called known-plaintext attack. In a known-plaintext attack, the attacker knows at least a sample of couples $(pt x, c t x)$ , where $c t x$ is the encryption of $pt x$ . A famous example of this kind of attacker was Alan Turing when, in the early 40s, he discovered repetitive messages in the Enigma code corresponding to the greeting to Adolf Hitler.
A limit case of a known-plaintext attack is the chosen-plaintext attack: in this case the attacker actually chooses the plaintext, and can consequently see the corresponding ciphertext. It's a rarer condition.
We can anyway just focus on general known-plaintext attacks, as chosen-plaintext attacks are just a proper subset.

To analyze the situation, we consider the extreme case, where $P = {pt x_{1}, pt x_{2}}$ . At this point, if the encryption function is deterministic (as the ones seen so far), the cipher is not secure. In fact, even if the attacker knows only a pair $(pt x_{1}, c t x_{1})$ , he will be able to understand every message exchanged: if he reads $c t x_{1}$ , he knows that the original message is $pt x_{1}$ , vice versa $pt x_{2}$ .
This means that, in order for the cipher to be secure, the encryption function must be non-deterministic. Actually, there exists different paths we can follow to reach this goal:
A first, simple way is to manipulate the key every time it is used. Another common method is to choose each time a different number, called nonce, as starting point of the counter. But the most popular way to do it is probably the technique of rekeying, employed through what goes under the name of symmetric ratcheting. This method consists in producing a different key for every message through the use of a PRNG, that takes an input string of length $λ$ and stretches it into an output of length $2 λ$ : the first half of the output is used as a key, while the second half is used as input to the same function to produce another key, and so on. The initial input used to generate all the keys from there on is called seed.

The terms "ratcheting" derives from the fact that, as a ratchet can only turn on one side but cannot turn back, this mechanism ensures that, even finding a key, there's no way to know the previous ones.

What's Next?

We've locked down confidentiality, but what happens when the attacker can tamper with the ciphertext? Next up: integrity and hash functions.

Foundations of Cryptography: Information Theory & Security Models

Alberto Boffi — Sun, 16 Aug 2026 12:08:31 +0000

The Big Picture

Cryptography is the study of techniques to allow secure communication and data storage in the presence of attackers.

That's a good start, but it doesn't tell us much on its own. If we want to define cryptography in a more formal and precise way, we have to refer to the information theory, credited by Claude Shannon:

A communication is a flow of information over a channel that takes place between two endpoints: a sender, made of an information source and an encoder, and a receiver, made of an information destination and a decoder.

As convention, the two endpoints are usually called "Alice" and "Bob": you'll see these names everywhere in cryptography. The "information" can be modeled as strings of symbols belonging to a finite alphabet. Being in the computer science discipline, this alphabet is usually $Σ = {0, 1}$ . The ordinary readable string containing the information the sender wants to transmit is called message (or plaintext), while the encoded version of the message that is actually transmitted over the channel is the ciphertext.

A cryptosystem is a tuple $(P, C, K, E, D)$ , where:

The plaintext space $P = {0, 1}^{l}$ is the set of all possible plaintexts $pt x$ ;
The ciphertext space $C = {0, 1}^{l^{'}}$ is the set of all possible ciphertexts $c t x$ . Please note that, in general, $l \neq = l^{'}$ , i.e. the length of the plaintext does not necessarily have to coincide with that of the ciphertext;
The key space $K = {0, 1}^{λ}$ is the set of all possible keys $k$ ;
The encryption function $E$ is a function defined as $E : P \times K \to C$ ;
The decryption function $D$ is a function defined as $D : C \times K \to P$ .

A cipher is an implementation of the encryption function $E$ and decryption function $D$ such that, for every plaintext $pt x \in P$ , $\exists k, k^{'} \in K$ such that $D (E (pt x, k), k^{'}) = pt x$ . In case $k = k^{'}$ the cipher is called symmetric cipher, if instead $k \neq = k^{'}$ asymmetric cipher.

A cipher includes therefore an encryption algorithm that, given a key and a plaintext, produces a ciphertext, and a decryption algorithm that, given another key and any ciphertext produced during the encryption, returns the original plaintext. As we'll see, the functions $E$ and $D$ can also coincide.

How Do We Know If a Cipher Is Secure?

Before diving into the different kinds of ciphers, we should understand how to evaluate them, that is, what security requirements the ciphers must meet.

Here's the first thing that might surprise you:

An ideal attacker has complete knowledge of the cryptosystem in use.

This means that the attacker can access the plaintext, ciphertext and key space, and call the functions $E$ and $D$ as many times as he/she wants. Therefore, contrary to what some may think, hiding these elements cannot be considered a security requirement.
We will understand the importance of this assumption later on, and the reason why we can safely make it lies in Kerckhoff's second principle for a good cipher:

A cipher must be secure even if the cryptosystem is known to the enemy.

This means that the only thing that the attacker doesn't know is the specific plaintext the sender is communicating during a particular communication, or the specific keys in use. The main features a cipher can offer are the following (and depending on what you're building, some of these will matter more than others):

Confidentiality: The plaintext cannot be derived from the ciphertext without having the decryption key;
Integrity: The information transmitted cannot be tampered with along the channel;
Authenticity: The identity of the sender is guaranteed to the receiver.

Now that we've covered a high-level overview of ciphers, it's time to dive into how they actually work. We'll start with the most intuitive category: symmetric ciphers.