Unlocking Secure Futures: The Power of Cryptographic Randomness in WebAssembly WASI

In our increasingly interconnected digital world, the need for robust security is paramount. From safeguarding financial transactions across continents to ensuring the fairness of online gaming and protecting personal data, the underlying mechanisms must be unimpeachable. One such fundamental mechanism, often overlooked but critical to modern cybersecurity, is the generation of truly random numbers. When we speak of "randomness" in a computational context, especially for security-sensitive applications, we are not talking about simple unpredictability. We are referring to cryptographically secure randomness.

This comprehensive guide delves into the fascinating and vital realm of cryptographic random number generation, specifically within the innovative ecosystem of WebAssembly (Wasm) and the WebAssembly System Interface (WASI). We will explore why secure randomness is a non-negotiable requirement for global applications, how Wasm and WASI address this challenge, and the profound implications for building a more secure and trustworthy digital future across diverse industries and geographical boundaries.

The Global Need for Randomness: More Than Just Chance

Imagine a digital world where every encryption key could be guessed, where every lottery number was predictable, or where every secure connection was compromised. This is the reality we face if our random number generation is not truly secure. Randomness is the bedrock upon which many cryptographic primitives are built. Without it, the strongest algorithms can be rendered useless.

What is Randomness, and Why Does it Matter So Much?

At its core, randomness refers to a lack of pattern or predictability. For cryptographic purposes, however, this definition is elevated. A cryptographically secure random number generator (CSPRNG) must produce numbers that are not only unpredictable to an observer, even with full knowledge of previous outputs, but also resistant to efforts to determine the initial "seed" from which the numbers are derived.

The significance of this is hard to overstate. Consider these scenarios:

• Encryption Keys: When you establish a secure connection (e.g., HTTPS for banking or secure messaging), unique session keys are generated. If these keys are predictable, an attacker could intercept and decrypt your private communications.
• Digital Signatures: Cryptographic signatures authenticate identities and verify data integrity. Their security relies on random parameters to prevent forgery.
• Blockchain Technologies: From generating wallet addresses to selecting block proposers in certain consensus mechanisms, blockchain heavily relies on unpredictable random numbers to ensure fairness and security across a decentralized, global network.
• Token Generation: One-time passwords (OTPs), authentication tokens, and unique identifiers (UUIDs) often require strong randomness to prevent brute-force attacks or collisions.
• Statistical Sampling and Simulations: While not always security-critical, accurate scientific simulations and fair statistical sampling for global research projects also benefit immensely from high-quality randomness.

In each of these cases, and countless others, a weak or compromised random number generator is a critical vulnerability, exposing users and systems worldwide to significant risks.

The Universal Challenge: Generating Truly Random Numbers

Computers are deterministic machines. They follow instructions precisely. This inherent determinism makes generating true randomness a fundamental challenge. Traditional pseudo-random number generators (PRNGs) produce sequences that appear random but are entirely predictable if you know the initial seed and the algorithm. This is perfectly acceptable for non-security-critical tasks like shuffling a playlist, but disastrous for cryptography.

To achieve cryptographic randomness, systems typically rely on external sources of "entropy" – unpredictable physical phenomena that can be converted into random bits. These sources can include environmental noise, user input timings (mouse movements, keyboard strokes), hard drive seek times, or even quantum phenomena. The challenge is ensuring these entropy sources are truly random, harvested efficiently, and accessible consistently across diverse computing environments, from tiny embedded devices to massive cloud servers.

A Deep Dive into WebAssembly (Wasm) and WASI

Before we explore how WebAssembly tackles the randomness problem, let's briefly recap what Wasm and WASI are and why they are revolutionizing software development globally.

WebAssembly: The Universal Binary Format for the Web and Beyond

WebAssembly, often abbreviated as Wasm, is a low-level binary instruction format for a stack-based virtual machine. It is designed as a portable compilation target for high-level languages like C/C++, Rust, Go, and many others, enabling deployment on the web for client-side applications and on servers, IoT devices, and even blockchain runtimes. Its key features include:

• Performance: Near-native execution speeds.
• Portability: Runs consistently across different hardware and operating systems.
• Security: Runs in a sandboxed environment, preventing direct access to the host system.
• Compactness: Small binary sizes, fast loading.

Wasm has moved beyond just browsers, finding significant traction in serverless computing, edge computing, and as a universal runtime for decentralized applications (Web3). Its promise of "write once, run anywhere" with high performance is truly a global proposition.

WASI: Bridging the Gap to System Resources

While Wasm provides a powerful execution environment, its inherent sandboxing means it cannot directly interact with the underlying operating system for tasks like reading files, accessing network sockets, or, crucially, requesting random numbers. This is where the WebAssembly System Interface (WASI) comes in.

WASI is a modular system interface for WebAssembly. It defines a set of standardized APIs that allow Wasm modules to securely access host system resources in a platform-independent manner. Think of WASI as a POSIX-like interface for Wasm. It allows Wasm programs to be compiled once and then run on any operating system that provides a WASI runtime (e.g., Node.js, Wasmtime, Wasmer), granting them controlled access to functionalities typically reserved for native applications.

The design philosophy behind WASI prioritizes security. Instead of granting blanket access, WASI uses a capability-based security model, where modules must be explicitly granted permissions for specific resources (e.g., file system access to a particular directory, or the ability to generate random numbers). This fine-grained control is vital for maintaining the security guarantees of the Wasm sandbox while expanding its utility.

The Critical Intersection: Randomness in WebAssembly and WASI

Given Wasm's sandboxed nature and its increasing role in security-sensitive applications globally, providing a reliable and cryptographically secure source of randomness becomes absolutely essential. This is precisely where WASI plays a pivotal role.

The Problem: Determinism vs. Non-Determinism in Wasm Environments

By design, a pure Wasm module is deterministic. Given the same inputs, it will always produce the same outputs. This determinism is a powerful feature for reproducibility and verification, especially in scenarios like smart contracts on a blockchain where every node must arrive at the identical state. However, cryptographic operations fundamentally rely on non-determinism – the ability to produce outputs that cannot be predicted.

If a Wasm module running in an isolated environment tries to generate random numbers without external help, it would either produce predictable sequences (if using a simple PRNG seeded with a fixed value) or be entirely unable to generate any randomness. Neither scenario is acceptable for security. A Wasm module running in your browser, a cloud function, or a blockchain validator needs access to strong, unpredictable random data.

The Solution: WASI's Role in Providing Cryptographic Randomness

WASI addresses this by providing a standardized API for accessing cryptographically secure random numbers from the host environment. This means that instead of attempting to generate randomness within the deterministic Wasm sandbox, the Wasm module delegates this critical task to the trusted host. The host operating system (Linux, Windows, macOS, etc.) is responsible for maintaining a pool of high-quality entropy and providing secure random bytes.

This approach has several significant advantages:

• Leverages Host Security: The host OS's existing, well-vetted CSPRNG (e.g., /dev/urandom on Linux, CryptGenRandom on Windows) is typically highly optimized and robust, drawing from diverse, high-quality entropy sources.
• Standardization: Developers can write Wasm code that requests random numbers using a single, portable WASI API, regardless of the underlying host. This fosters interoperability and reduces platform-specific code.
• Sandbox Integrity: The Wasm module remains sandboxed. It doesn't need to understand the intricacies of entropy collection; it simply makes a request, and the host fulfills it securely.

How WASI 'random_get' Works: A Secure Approach

The core WASI function for obtaining cryptographically secure random bytes is random_get. It's part of the wasi_snapshot_preview1 API, which is widely implemented.

The signature of random_get (conceptually, as seen by a Wasm module) typically looks something like this:

random_get(buffer_pointer: u32, buffer_len: u32) -> error_code

• buffer_pointer: A pointer to a region of memory within the Wasm module's linear memory where the random bytes should be written.
• buffer_len: The number of random bytes requested.
• error_code: A return value indicating success or failure (e.g., insufficient permissions, host error).

When a Wasm module calls random_get, the WASI runtime (provided by the host) intercepts this call. It then translates this request into a system call to the host's underlying CSPRNG. The host OS generates the requested number of cryptographically secure random bytes and writes them back into the Wasm module's designated memory region. The Wasm module can then use these bytes for its cryptographic operations.

This abstraction is powerful. A Rust program compiled to Wasm can use rand::thread_rng(), which under the hood, when compiled for WASI, will eventually make a call to random_get. Similarly, C/C++ programs might use standard library functions like getrandom() or CryptGenRandom() (or their wrappers), which the WASI runtime maps appropriately.

Understanding Cryptographically Secure Pseudo-Random Number Generators (CSPRNGs)

Since WASI relies on the host's CSPRNG, it's crucial for developers and architects to understand what makes these generators secure and how they differ from their simpler counterparts.

What Makes a CSPRNG "Secure"?

A CSPRNG is designed to meet stringent requirements that ensure its output is suitable for cryptographic use. Key properties include:

• Unpredictability: An attacker cannot predict future outputs even if they know all past outputs.
• Non-reconstructibility: An attacker cannot determine the internal state or seed of the generator, even if they know all past and future outputs.
• Resistance to Seed Compromise: If the internal state (seed) of the generator is compromised at some point, subsequent outputs should remain unpredictable from prior outputs. This is often achieved through a process called re-seeding or forward secrecy, where the internal state is regularly updated with new entropy.
• High Entropy Output: The output must be statistically indistinguishable from truly random numbers.

These properties make CSPRNGs suitable for generating long-term keys, session keys, nonces (numbers used once), salts for password hashing, and other critical security parameters.

Entropy Sources: The Lifeblood of Cryptographic Randomness

The quality of a CSPRNG is directly tied to the quality and quantity of entropy it can harvest. Entropy is essentially true randomness drawn from physical processes. Common entropy sources include:

• Hardware Random Number Generators (HRNGs): Dedicated hardware components (often found in CPUs or specialized chips) that exploit quantum phenomena like thermal noise, atmospheric noise, or semiconductor noise. These are generally considered the highest quality sources.
• System Events: Interrupt timings, hard drive latency, network packet arrival times, process IDs, memory usage, and other operating system-level events can contribute to an entropy pool.
• User Input: Mouse movements, keyboard timings, and other user interactions, while limited, can provide some entropy in desktop environments.

Operating systems maintain an "entropy pool" that continuously gathers bits from these sources. When a CSPRNG needs to be seeded or re-seeded, it draws from this pool. The robustness of a host's CSPRNG depends heavily on its ability to collect diverse and high-quality entropy.

Distinguishing CSPRNGs from PRNGs

It is vital to understand the difference between a simple Pseudo-Random Number Generator (PRNG) and a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). Using a PRNG for security purposes is one of the most common and dangerous cryptographic mistakes.

• PRNGs (e.g., rand() in C, java.util.Random):
  • Primarily for non-security tasks (simulations, gaming where fairness isn't critical, shuffling).
  • Fast to generate.
  • Predictable: If the seed is known, the entire sequence can be reproduced.
  • Statistically good but cryptographically weak.
• CSPRNGs (e.g., /dev/urandom, CryptGenRandom, java.security.SecureRandom):
  • Essential for all security-sensitive tasks (key generation, nonces, salts).
  • Slower than PRNGs due to entropy gathering and more complex algorithms.
  • Unpredictable: Even with full knowledge of past outputs, future outputs cannot be guessed.
  • Resistant to attacks to discover the seed or internal state.
  • Relies on high-quality entropy from the environment.

WASI's random_get specifically provides access to the host's CSPRNG, ensuring that Wasm applications can obtain the level of randomness required for critical security operations.

Practical Applications and Use Cases Across Industries

The ability to securely generate random numbers within Wasm/WASI environments opens up a vast array of possibilities, enhancing security and functionality across numerous global industries.

Blockchain and Cryptocurrencies: Ensuring Transactional Integrity

Blockchain technology, by its decentralized nature, demands robust security and fairness. Wasm is increasingly becoming a preferred runtime for smart contracts and blockchain clients due to its performance, portability, and sandboxing. Cryptographically secure randomness is indispensable here:

• Wallet Address Generation: Private keys, from which public keys and wallet addresses are derived, must be generated with strong randomness to prevent collisions and ensure the uniqueness and security of funds.
• Decentralized Applications (dApps): Many dApps, particularly in decentralized finance (DeFi) and gaming (GameFi), require randomness for features like fair lotteries, unique NFT minting, or selecting validators in certain Proof-of-Stake consensus mechanisms.
• Randomness Beacons: Some blockchain protocols seek external, verifiable random numbers for various operations. Wasm/WASI could enable secure clients to consume these beacons.

The global impact is significant: secure WASI-enabled blockchain applications mean more trustworthy financial systems, verifiable digital assets, and fair decentralized ecosystems for users worldwide.

Secure Communication and Encryption: Protecting Global Data

Every secure communication channel, from encrypted email to instant messaging and VPNs, relies on random numbers for key generation and session establishment. Wasm could play a role in:

• Secure Client-Side Encryption: Wasm modules could perform cryptographic operations directly in the browser or on the edge, generating keys for end-to-end encrypted communications without relying on a centralized server.
• IoT Device Security: Resource-constrained IoT devices often need to generate unique device IDs or cryptographic keys. Wasm/WASI could provide a secure, portable runtime for these operations, ensuring device integrity across a vast global network of sensors and actuators.
• VPN Clients and Proxies: Wasm can power high-performance, secure components within VPN clients, handling cryptographic handshakes and tunnel establishment with robust randomness.

This enables a higher standard of data privacy and security for individuals and organizations communicating across borders, protecting sensitive information from interception and tampering.

Gaming and Simulation: Fairness and Unpredictability

While not always considered "cryptographic," fairness in gaming and statistical accuracy in simulations demand high-quality randomness. WASI's CSPRNG access ensures:

• Fair Online Gaming: For features like loot box drops, card shuffling in poker, dice rolls, or critical hit calculations in online role-playing games, cryptographically secure randomness can ensure that outcomes are truly unpredictable and cannot be manipulated by players or operators. This builds trust in global gaming communities.
• Scientific Simulations: Large-scale scientific models (e.g., climate change, molecular dynamics, population genetics) often require vast quantities of high-quality random numbers for Monte Carlo simulations. Wasm/WASI can provide a portable, high-performance platform for these computations, ensuring the integrity of research conducted by institutions worldwide.

Scientific Research and Data Anonymization: Preserving Privacy and Accuracy

In research that involves sensitive data, randomness is crucial for anonymization and statistical integrity:

• Differential Privacy: Adding carefully calibrated random noise to datasets is a technique used to achieve differential privacy, allowing statistical analysis without revealing individual data points. Wasm/WASI could power privacy-preserving data analysis modules.
• Randomized Control Trials (RCTs): In medical or social science research, random assignment of participants to control and treatment groups is essential. Secure randomness ensures unbiased results, applicable across diverse demographic and geographic cohorts.

Distributed Systems and Global Load Balancing

Modern cloud architectures and distributed systems, often spanning multiple data centers across the globe, benefit from unpredictable randomness for:

• Distributed Consensus: Certain distributed algorithms, such as leader election in some consensus protocols, can use randomness to break ties or ensure fairness.
• Unique ID Generation: Generating universally unique identifiers (UUIDs) across distributed services without collision requires strong randomness, vital for tracking requests and resources in complex global microservice architectures.
• Dynamic Resource Allocation: Randomization can be used in some load balancing strategies or resource allocation algorithms to distribute workloads fairly and prevent hotspots.

Implementing Cryptographic Randomness in Wasm/WASI Applications

For developers keen on leveraging WASI's cryptographic randomness, understanding the implementation details and best practices is crucial.

Leveraging WASI random_get in Different Languages

The beauty of WASI is that it abstracts away the underlying operating system. Developers writing in their preferred language compile their code to Wasm, and the language runtime or standard library handles the WASI calls.

• Rust: Rust's popular rand crate is well-integrated with WASI. When compiling a Rust application to Wasm with a WASI target (e.g., wasm32-wasi), calls to rand::thread_rng() or rand::rngs::OsRng will automatically be mapped to WASI's random_get by the Rust standard library. This provides a familiar and secure interface for Rust developers worldwide.

          
          use rand::Rng;
  
          fn main() {
              let mut rng = rand::thread_rng();
              let random_byte: u8 = rng.gen();
              println!("Random byte: {}", random_byte);
  
              let mut buffer = [0u8; 32];
              rng.fill(&mut buffer[..]);
              println!("32 random bytes: {:?}", buffer);
          }
          
          

• C/C++: For C/C++ applications compiled to WASI, the standard library functions typically used for secure randomness (e.g., arc4random_buf() or potentially custom wrappers around /dev/urandom-like functionality) would be mapped to WASI's random_get by the WASI libc implementation. Developers should avoid rand() and srand() for security-sensitive contexts.

          
          // Example (conceptual, actual implementation depends on WASI libc)
          #include <stdio.h>
          #include <stdint.h>
          #include <stdlib.h> // For arc4random_buf or similar
  
          // In a WASI environment, arc4random_buf might be mapped to random_get
          extern void arc4random_buf(void *buf, size_t nbytes);
  
          int main() {
              uint8_t buffer[32];
              arc4random_buf(buffer, sizeof(buffer));
  
              printf("32 random bytes: ");
              for (size_t i = 0; i < sizeof(buffer); ++i) {
                  printf("%02x", buffer[i]);
              }
              printf("\n");
              return 0;
          }
          
          

• Go: With Go's experimental WASI support, packages like crypto/rand are expected to be correctly mapped to WASI random_get, providing the necessary cryptographic randomness.

          
          package main
  
          import (
              "crypto/rand"
              "fmt"
              "log"
          )
  
          func main() {
              b := make([]byte, 32)
              _, err := rand.Read(b)
              if err != nil {
                  log.Fatal(err)
              }
              fmt.Printf("32 random bytes: %x\n", b)
          }
          
          

• AssemblyScript: As a TypeScript-to-WebAssembly compiler, AssemblyScript often relies on host functions for system-level operations. For cryptographic randomness, it would typically import a host function that in turn calls WASI random_get.

          
          // In AssemblyScript
          // Assuming a host function 'randomGet' is imported and handles the WASI call
          @external("env", "randomGet")
          declare function randomGet(ptr: usize, len: usize): void;
  
          export function generateRandomBytes(len: i32): Uint8Array {
              let buffer = new Uint8Array(len);
              randomGet(buffer.dataStart, buffer.byteLength);
              return buffer;
          }
  
          // Host-side (e.g., in Node.js with a WASI runtime)
          // const instance = await WebAssembly.instantiate(..., {
          //     env: {
          //         randomGet: (ptr, len) => {
          //             // Use node's crypto.randomFillSync or similar
          //             const randomBytes = crypto.randomBytes(len);
          //             // Write to Wasm memory at 'ptr'
          //         }
          //     }
          // });
          
          

Best Practices for Secure Random Number Generation

Even with WASI providing access to a CSPRNG, developers must follow best practices to ensure the security of their applications:

• Always Use CSPRNGs for Security: Never use simple PRNGs (e.g., those based on time() as a seed) for any security-sensitive purpose. Always opt for the cryptographically secure options provided by language standard libraries (which delegate to WASI random_get).
• Request Sufficient Entropy: Ensure you request enough random bytes for your specific cryptographic needs. For example, 256 bits (32 bytes) is a common recommendation for strong encryption keys.
• Handle Errors Gracefully: The random_get function (or its language wrappers) can potentially fail (e.g., if the host runs out of entropy or has a security policy preventing access). Your application must handle these errors robustly, perhaps by failing securely or alerting administrators, rather than proceeding with weak or predictable values.
• Regularly Re-seed (Host Responsibility): While WASI delegates this to the host, it's good to understand that a robust CSPRNG implementation on the host will continuously gather new entropy and re-seed itself to maintain forward secrecy.
• Auditing and Review: Regularly audit your code and its dependencies to ensure that all randomness requirements are met securely. Stay informed about any vulnerabilities found in underlying CSPRNG implementations or WASI runtimes.

Pitfalls to Avoid: Common Mistakes in Randomness Implementation

Even with access to CSPRNGs, mistakes can compromise security. Developers, especially those new to cryptographic programming, should be aware of these common pitfalls:

• Using Weak Seeds: Seeding a PRNG with predictable values (like current time or process ID) makes it entirely insecure. This is less of an issue with WASI's direct access to CSPRNGs, but still a general principle.
• Not Requesting Enough Randomness: Using too few random bits (e.g., 64-bit keys when 256 bits are required) significantly weakens security.
• Truncating Randomness: Taking only a portion of the output from a CSPRNG without careful consideration can sometimes introduce bias or reduce entropy.
• Reusing Nonces or Keys: Using the same nonce (Number Used ONCE) or cryptographic key for multiple operations can lead to severe security vulnerabilities, enabling replay attacks or key recovery.
• Building Custom Randomness Generators: Unless you are a seasoned cryptographer with extensive peer review, never attempt to implement your own CSPRNG. Always rely on well-vetted, standard library implementations that leverage the operating system's robust facilities.
• Ignoring Host Environment: While WASI abstracts the host, the security of the host's underlying CSPRNG is paramount. An insecure or compromised host environment can still undermine the Wasm module's security, emphasizing the need for secure deployment practices globally.

The Global Impact and Future of Secure Randomness in the Wasm Ecosystem

The standardization of cryptographic randomness through WASI is a significant step forward for the entire WebAssembly ecosystem. Its implications resonate across various dimensions of global software development and cybersecurity.

Enhancing Trust and Security in Distributed Computing

As Wasm continues to expand its footprint from the browser to the server, edge devices, and decentralized networks, the ability to obtain high-quality, cryptographically secure random numbers consistently is fundamental. It means that applications built on Wasm/WASI can now confidently handle sensitive data, generate secure keys, and participate in complex cryptographic protocols, regardless of where they are deployed globally.

This fosters a greater degree of trust in distributed systems. For instance, a Wasm module running on an IoT device in a remote location can generate unique, secure credentials, knowing that the randomness source is as reliable as a server in a major data center, thanks to WASI. This uniformity of security primitives is a powerful enabler for global innovation.

Standardization Efforts and Community Contributions

The WASI specification is an open standard, driven by a collaborative community. This open development model is crucial for security, as it allows for widespread peer review, rapid identification of potential issues, and continuous improvement. As new cryptographic challenges emerge and new entropy sources become available, the WASI specification can evolve to incorporate them, maintaining its relevance and robustness.

Community contributions, ranging from proposals for new WASI APIs to implementations in various languages and runtimes, are vital. This global collaboration ensures that the WASI ecosystem remains cutting-edge and addresses the diverse needs of developers and enterprises worldwide.

Looking Ahead: WASI Evolution and Advanced Primitives

The journey of WASI is far from over. Future iterations of WASI might include more advanced cryptographic primitives, potentially offering direct access to hardware security modules (HSMs) or trusted execution environments (TEEs) if available on the host. This could further enhance the security posture of Wasm applications, especially in highly sensitive domains like finance, national security, and critical infrastructure.

Furthermore, as new research in post-quantum cryptography advances, WASI could provide mechanisms for Wasm modules to access quantum-resistant random number generators or cryptographic algorithms, preparing the ecosystem for future security landscapes. The modular nature of WASI makes it incredibly adaptable to such future requirements, solidifying its role as a foundation for secure computing globally.

Conclusion: Building a More Secure and Predictable Digital Future

Cryptographically secure random number generation is a silent hero of the digital age, a fundamental building block upon which much of our modern security infrastructure rests. With the advent of WebAssembly and WASI, this critical capability is now reliably and portably available to a new generation of high-performance, sandboxed applications.

Recap of Key Takeaways

• Randomness is Crucial: For all security-sensitive applications, cryptographically secure randomness is non-negotiable for key generation, nonces, and overall system integrity.
• Wasm's Determinism Requires External Help: Due to its sandboxed, deterministic nature, Wasm needs a secure way to access non-deterministic entropy.
• WASI Provides the Solution: The WebAssembly System Interface (WASI) standardizes access to the host operating system's CSPRNG via functions like random_get, ensuring high-quality randomness.
• CSPRNGs are Different: Always distinguish between simple PRNGs and CSPRNGs, using the latter for all security contexts. CSPRNGs rely on high-quality entropy sources.
• Global Impact: This capability empowers secure applications in blockchain, secure communication, gaming, scientific research, and distributed systems worldwide.
• Best Practices are Essential: Even with WASI, developers must follow best practices, avoid common pitfalls, and leverage language-native secure random number APIs.

Call to Action for Developers and Architects

As developers and architects, embracing WebAssembly and WASI means building a future where applications are not only performant and portable but also inherently more secure. By understanding and correctly utilizing WASI's cryptographic random number generator, you contribute to a more trustworthy digital ecosystem that benefits users and organizations across every corner of the globe.

We encourage you to explore the WASI specification, experiment with compiling your code to Wasm/WASI, and integrate these powerful security primitives into your next generation of applications. The future of secure, distributed computing is being built today, and cryptographically secure randomness in WebAssembly WASI is a cornerstone of that foundation.