Skip to main content

Why is the Advanced Encryption Standard (AES) important?

Updated on
12 April 2026
Follow Us
02 February, 2021

The advanced encryption standard serves as the predominant symmetric block cipher standard adopted globally since 2001. Originally selected by the United States National Institute of Standards and Technology (NIST) in October 2000, the algorithm known as Rijndael was formally published as FIPS PUB 197 in November 2001. AES operates on fixed 128-bit data blocks and supports cryptographic keys of 128, 192, or 256 bits, replacing the weaker data encryption standard (DES) and Triple DES that had become vulnerable to modern computing power.

Today, AES underpins the security of everyday digital interactions. From HTTPS sessions and virtual private networks to disk encryption and financial messaging systems, the encryption algorithm protects electronic data across countless applications. For regulated financial institutions, InvestGlass relies on AES as a core building block to secure client data while preserving sovereignty within Swiss or on-premise infrastructures.

InvestGlass API and Security
InvestGlass API and Security

Historical Background and Standardisation

The data encryption standard, originally developed by IBM and standardised in 1977, became obsolete by the late 1990s. Its 56-bit key length proved fatally weak against brute force attacks. In 1997, the first RSA Data Security DES Challenge was cracked in 84 days. By 1998, the Electronic Frontier Foundation’s Deep Crack machine recovered a key in just 56 hours for under $250,000. These public demonstrations made clear that DES could no longer protect sensitive information.

In response, NIST launched a public competition in January 1997 to select a new block cipher secure enough for the coming decades. After initial screening reduced 21 submissions to 15 candidates from 12 countries, rigorous multi-year evaluations assessed each algorithm for:

  • Security against differential and linear cryptanalysis
  • Performance across 8-bit to 32-bit processors
  • Hardware and software efficiency
  • Implementation flexibility

On 2 October 2000, NIST selected the Rijndael algorithm designed by Belgian cryptographers Joan Daemen and Vincent Rijmen. The cipher offered an optimal balance of security margins, speed (up to three times faster than rivals in software), and minimal memory requirements.

Core standards governing AES include FIPS PUB 197 specifying the algorithm itself, ISO/IEC 18033-3 for block ciphers ensuring global interoperability, and NSA approval for protecting classified information in approved modules. European and Swiss institutions often rely on AES within sovereign infrastructures rather than on foreign-controlled cloud ecosystems, ensuring compliance with GDPR, the Swiss Federal Act on Data Protection, and local banking regulations.

Core Properties and Design of AES

The advanced encryption standard aes is a symmetric block cipher using a substitution-permutation network (SPN) structure rather than the Feistel network employed by DES. This architectural choice provides efficient parallel processing and strong resistance to known attacks.

Parameter

Value

Block size

128 bits

Key lengths

128, 192, or 256 bits

Rounds

10, 12, or 14 (respectively)

Data is represented as a 4×4 matrix of bytes called the state, processed column by column through multiple rounds of transformations. The same key is used for both encryption and decryption, making AES efficient for bulk data protection.

The security margin of AES has been studied extensively in public cryptography research. As of 2026, no practical attacks against full-round AES have been discovered, confirming its suitability for protecting sensitive data in financial records, national security systems, and commercial applications alike.

High-level AES Encryption Process

Each AES encryption instance begins with key expansion, where the key schedule algorithm derives round keys from the original encryption key. The overall structure follows a precise sequence:

  1. Initial AddRoundKey: XOR the plaintext with the first round key
  2. Full rounds (9, 11, or 13 depending on key size): Each round consists of SubBytes, ShiftRows, MixColumns, and AddRoundKey
  3. Final round: Omits MixColumns but includes SubBytes, ShiftRows, and AddRoundKey

This design provides confusion through non-linear substitution and diffusion through row shifting and column mixing, following Shannon’s foundational principles. The encryption process ensures that flipping a single plaintext bit alters roughly 50 per cent of ciphertext bits by the second round, with full diffusion achieved by round four.

Decryption applies the inverse transformations in reverse order using the same round keys, ensuring exact recovery of plaintext from encrypted data.

SubBytes and the AES S-box

SubBytes replaces each byte in the state with a value from a fixed 8-bit substitution box, introducing essential non-linearity into the aes cipher. The s box is constructed mathematically:

  1. Compute the multiplicative inverse in GF(2^8) modulo the irreducible polynomial x^8 + x^4 + x^3 + x + 1
  2. Apply an affine transformation via matrix multiplication over GF(2)

This construction resists differential cryptanalysis (probability ≤ 4/256 per active S-box) and linear cryptanalysis (bias ≤ 2^-6). The byte substitution operation contains no fixed points or hidden structures, avoiding suspected backdoors. This mathematical transparency is particularly important for sovereignty-conscious organisations wary of proprietary hardware.

During decryption, an inverse S-box reverses the substitution while preserving security properties. Implementations may use a 256-entry lookup table for speed or compute values on the fly for enhanced side-channel resistance.

ShiftRows and MixColumns

ShiftRows cyclically shifts the rows of the state left by different offsets:

Row

Shift (bytes left)

First row

0

Second row

1

Third row

2

Fourth row

3

This operation spreads byte influence across columns, breaking any patterns that might otherwise persist. The corresponding byte positions become interleaved, preparing the state for the next transformation.

MixColumns treats each column as a polynomial over GF(2^8) and multiplies it by a fixed matrix modulo an irreducible polynomial. This matrix multiplication ensures each input byte affects all four output bytes within its column. Together, ShiftRows and MixColumns provide strong diffusion, ensuring that changes propagate throughout the entire data block.

MixColumns is omitted in the final round to preserve reversibility without weakening practical security. During decryption, inverse ShiftRows (shifted cyclically to the right) and inverse MixColumns recover the original state.

AddRoundKey and Key Schedule

AddRoundKey performs a simple bitwise XOR of the 128-bit state with a round key derived from the initial secret key. Despite its simplicity, this step is essential for whitening the state and preventing linear attacks.

The key schedule algorithm generates round keys through:

  • Word rotations (RotWord)
  • S-box substitutions (SubWord)
  • XOR with round constants (Rcon values)
  • Chaining operations to prevent symmetry attacks

The schedule differs between key sizes. AES-128 expands 4 words into 44 for 10 rounds, while AES-256 requires additional processing steps for its 14 rounds.

The secrecy of the original key and correct implementation of the key schedule are critical. Exposure of round keys compromises the entire cipher. Robust key management frameworks are essential in production environments, including:

  • Hardware security modules (HSMs)
  • Role-based access control
  • Key rotation policies
  • Separation of duties

These controls are particularly vital in banking, insurance, and public sector deployments where a data breach could have severe regulatory and reputational consequences.

Security Strength, Key Sizes, and Quantum Considerations

AES-128, AES-192, and AES-256 offer increasing security levels with corresponding performance overheads. AES-256 typically runs 20-30 per cent slower than AES-128 in software implementations.

Key Size

Brute Force Complexity

Quantum (Grover) Complexity

128 bits

2^128 operations

2^64 operations

192 bits

2^192 operations

2^96 operations

256 bits

2^256 operations

2^128 operations

Brute force attacks against AES-128 already require infeasible resources. At 10^18 operations per second, exhausting all possible key combinations would take longer than the age of the universe. AES-256 is chosen for long-term or highly sensitive data, such as archival financial records requiring protection for decades.

Regarding quantum threats, Grover’s algorithm roughly halves the effective bit key length. This positions AES-256 as the preferable choice for post-quantum transitional strategies. For many commercial applications, AES-128 remains acceptable today, but institutions with long-lived data often standardise on the 256 bit key for additional margin against future advances in current technology.

Known Cryptanalytic Results

Published attacks on AES mainly target reduced-round variants or related key scenarios, not full 10, 12, or 14-round implementations with independent random keys.

Academic work includes:

  • Differential and linear cryptanalysis
  • Integral and boomerang attacks
  • Biclique techniques (achieving 2^126.1 complexity against full AES-128, still impractical)
  • Related key attacks (irrelevant when keys are properly randomised)

Security assessments by NIST and independent researchers continue to monitor new results. The consensus remains that AES maintains security margins exceeding two rounds beyond any known attacks.

In practice, implementation flaws and side channel attacks pose far greater risks than direct attacks on the aes algorithm itself. Regulated organisations should rely on certified modules and audited libraries rather than custom cryptographic code.

Digital onboarding score and fraud detection
Digital onboarding score and fraud detection

Side-channel and Implementation Attacks

Side-channel attacks exploit information leaked through timing, power consumption, cache behaviour, or electromagnetic leaks rather than breaking AES mathematically. These represent the most realistic threat vector for production systems.

Timing and cache attacks target table-based implementations. In shared environments like virtualised servers, attackers can observe memory access patterns to recover keys. The 2005 Bernstein attack demonstrated key recovery in seconds on shared CPUs running OpenSSL.

Power analysis and EM attacks can reveal secret information from embedded systems and smartcards. Simple differential power analysis may require only 1,000 traces to extract key material if countermeasures are absent.

Fault attacks deliberately inject errors during encryption through voltage glitches or laser pulses. Analysing the resulting faulty outputs can reveal key bytes with remarkably few faults.

Mitigation strategies include:

  • Constant-time code without data-dependent branches
  • Masking and blinding techniques to randomise intermediate values
  • Hardware acceleration (AES-NI on Intel processors since 2010)
  • Physical security controls around critical infrastructure
  • FIPS 140-3 validated modules with tested side-channel resistance

Best Practices to Harden AES in Production

Organisations should adopt these practices to ensure AES-based protections resist both software and physical attack vectors:

  1. Use well-reviewed libraries: Select actively maintained cryptographic libraries providing constant-time AES primitives
  2. Implement strong key management: Deploy HSMs, enforce role-based access, establish rotation policies
  3. Enforce secure configurations: Use authenticated modes (GCM, CCM), random 96-bit nonces, high-quality randomness sources
  4. Conduct regular testing: Perform penetration testing and code review focused specifically on cryptographic usage
  5. Avoid ECB mode: Never use Electronic Codebook mode, which reveals patterns in all the data

InvestGlass follows these principles within its architecture, ensuring that AES-based protections meet the stringent requirements of regulated financial environments.

Modes of Operation and Practical Usage

AES by itself is a block cipher operating on single 128-bit blocks. To encrypt data of arbitrary length securely, it must be combined with a mode of operation.

Mode

Type

Use Case

ECB

Confidentiality only

Avoid – reveals patterns

CBC

Confidentiality only

Legacy systems

CTR

Confidentiality only

Stream-like encryption

XTS

Confidentiality only

Disk encryption

GCM

AEAD

Network protocols, APIs

CCM

AEAD

Wireless security, IoT

Authenticated encryption with associated data (AEAD), especially AES-GCM, is widely recommended for modern protocols. GCM provides both confidentiality and integrity verification through GHASH authentication with 128-bit tags.

Misusing modes can catastrophically weaken security. Reusing IVs in GCM or using ECB mode exposes encrypted data to pattern analysis, even though the aes cipher itself remains sound. Financial platforms like InvestGlass rely on industry-standard AEAD modes to safeguard transactional and personal data at rest and in transit.

Examples of AES in Everyday Technologies

AES appears throughout modern digital infrastructure, protecting sensitive information across diverse applications:

  • TLS 1.3/HTTPS: Mandates AES-GCM for secure web sessions (covering over 99 per cent of web traffic)
  • WPA2/WPA3: Uses AES-CCMP for wireless networks security
  • IPsec VPNs: Secures virtual private networks for enterprise communications
  • BitLocker/FileVault: Provides full disk encryption using AES-XTS
  • Cloud storage: AWS S3, Azure, and other providers use AES-256 for server-side encryption
  • Payment systems: PCI DSS requires strong encryption for cardholder data and login credentials
  • Secure messaging: iMessage and similar apps use AES-CTR for message confidentiality

InvestGlass integrates AES-based encryption into its CRM, digital onboarding, portfolio management, and client portal layers. This ensures that sensitive financial data, from client profiles to transaction records, receives protection meeting international standards.

InvestGlass Digital Forms
InvestGlass Digital Forms

Regulation, Certification, and Data Sovereignty

AES frequently appears as a requirement within regulatory frameworks and security baselines. Key certifications include:

  • FIPS 140-2/140-3: Validates cryptographic modules for US federal use
  • NIST FIPS algorithm validation: Confirms correct AES implementation
  • ISO/IEC 18033-3: Ensures global interoperability
  • PCI DSS 4.0: Requires strong encryption for payment data

Supervisory bodies across Europe, the United Kingdom, and Switzerland expect robust encryption controls for banking, insurance, and public sector systems. The algorithm itself is standardised globally, but institutions must consider where encryption keys and encrypted data are physically stored and who can compel access.

Swiss-hosted or on-premise deployments using AES allow organisations to combine global cryptographic standards with strict national data-protection laws, avoiding jurisdictional conflicts that might arise with foreign-hosted solutions.

AES within Sovereign, Non-American, Non-Chinese Infrastructures

Many institutions wish to avoid exclusive reliance on American or Chinese cloud and CRM platforms. Concerns include:

  • Extraterritorial laws (such as the US CLOUD Act)
  • Geopolitical risks affecting data access
  • Regulatory uncertainty in cross-border transfers

AES itself is neutral and open, published without patent restrictions. However, control over the surrounding platform, hosting, and key management determines true sovereignty.

InvestGlass, as a Swiss sovereign CRM and automation platform, uses AES within infrastructure that can be hosted entirely in Switzerland or deployed on-premise. This architecture allows banks, wealth managers, insurers, and public-sector bodies to retain full control over cryptographic keys and client data.

By combining AES with Swiss data-protection regimes and European regulatory alignment, InvestGlass offers a sovereign alternative to American or Chinese technology stacks, protecting the sovereignty of client data without sacrificing the stronger security provided by world-class cryptography.

Choosing and Implementing AES in Financial and Regulated Environments

For decision-makers in financial institutions, the choice around AES typically concerns configuration and governance rather than the core algorithm. Key considerations include:

Decision

Recommendation

Key length

AES-256 for data requiring protection beyond 10 years

Mode

GCM or CCM for authenticated encryption

Key management

HSMs with customer-controlled access

Validation

FIPS 140-3 certified modules

Integration with identity and access management, comprehensive logging, and compliance reporting demonstrates that encryption operates in line with standards such as PCI DSS, EBA guidelines, and local banking regulations.

Platforms like InvestGlass embed AES-based controls into CRM workflows, digital onboarding, portfolio reporting, and client portals. This simplifies compliance for end institutions, providing secure data handling without requiring deep cryptographic expertise from every team member.

How InvestGlass Uses AES to Protect Client Sovereignty

InvestGlass encrypts sensitive CRM fields, onboarding documents, and portfolio data using AES within a Swiss or on-premise environment under the customer’s jurisdiction. The implementation covers:

  • Data at rest: Databases and file stores encrypted with AES-256
  • Data in transit: TLS sessions secured with AES-based cipher suites
  • Key management options: Customer-controlled, Swiss provider-managed, or HSM-based

This architecture enables financial institutions to comply with European and Swiss regulations while avoiding lock-in to American or Chinese cloud ecosystems. Clients maintain control over their encryption keys, ensuring that no foreign jurisdiction can compel access to decrypt data without proper legal process in the customer’s own country.

By combining AES with a sovereign platform, organisations align strong technical cryptography with legal and strategic data-sovereignty requirements. The result is secure communications, protected financial records, and full regulatory compliance delivered through a single integrated solution.

InvestGlass Agentic AI for sales and bankers
InvestGlass Agentic AI for sales and bankers

Key Takeaways

  • AES replaced the obsolete data encryption standard and remains unbroken against all known attacks after 25 years of public scrutiny
  • The algorithm processes data blocks through multiple rounds of substitution, shifting, mixing, and key addition
  • Key sizes of 128, 192, or 256 bits offer scalable security, with AES-256 preferred for long-term protection and quantum resilience
  • Side-channel attacks pose greater practical risks than mathematical breaks, making implementation quality critical
  • Authenticated modes like GCM provide both confidentiality and integrity for secure data handling
  • True data sovereignty requires control over hosting, key management, and platform governance, not just the encryption algorithm

For organisations seeking to protect sensitive information while maintaining full control over their digital infrastructure, combining AES with a sovereign platform like InvestGlass delivers both world-class cryptography and genuine data sovereignty. Consider exploring how Swiss-hosted or on-premise deployment could strengthen your institution’s security posture and regulatory compliance.

Related articles


Swiss Sovereign CRM: Built on AI.
Ready to act.

Main-InvestGlass-Features-Circle