Post-Quantum Cybersecurity Resources

Synopsis

NSA continues to evaluate the usage of cryptography solutions to secure the transmission of data in National Security Systems. NSA does not recommend the usage of quantum key distribution and quantum cryptography for securing the transmission of data in National Security Systems (NSS) unless the limitations below are overcome.

What are Quantum Key Distribution (QKD) and Quantum Cryptography (QC)?

Quantum key distribution utilizes the unique properties of quantum mechanical systems to generate and distribute cryptographic keying material using special purpose technology. Quantum cryptography uses the same physics principles and similar technology to communicate over a dedicated communications link. Published theories suggest that physics allows QKD or QC to detect the presence of an eavesdropper, a feature not provided in standard cryptography.

Quantum-resistant algorithms are implemented on existing platforms and derive their security through mathematical complexity. These algorithms used in cryptographic protocols provide the means for assuring the confidentiality, integrity, and authentication of a transmission—even against a potential future quantum computer. The National Institute of Standards and Technology (NIST) is presently conducting a rigorous selection process to identify quantum-resistant (or post-quantum) algorithms for standardization¹. Once NIST completes its selection process, NSA will issue updated guidance through CNSSP-15.

Understanding the QKD/QC story

Quantum key distribution and Quantum cryptography vendors—and the media—occasionally state bold claims based on theory—e.g., that this technology offers “guaranteed” security based on the laws of physics. Communications needs and security requirements physically conflict in the use of QKD/QC, and the engineering required to balance these fundamental issues has extremely low tolerance for error. Thus, security of QKD and QC is highly implementation-dependent rather than assured by laws of physics. Although we refer to QKD only to simplify discussion below, similar statements can be made for QC.

Technical limitations

 

1. Quantum key distribution is only a partial solution. QKD generates keying material for an encryption algorithm that provides confidentiality. Such keying material could also be used in symmetric key cryptographic algorithms to provide integrity and authentication if one has the cryptographic assurance that the original QKD transmission comes from the desired entity (i.e. entity source authentication). QKD does not provide a means to authenticate the QKD transmission source. Therefore, source authentication requires the use of asymmetric cryptography or preplaced keys to provide that authentication. Moreover, the confidentiality services QKD offers can be provided by quantum-resistant cryptography, which is typically less expensive with a better understood risk profile.

2. Quantum key distribution requires special purpose equipment. QKD is based on physical properties, and its security derives from unique physical layer communications. This requires users to lease dedicated fiber connections or physically manage free-space transmitters. It cannot be implemented in software or as a service on a network, and cannot be easily integrated into existing network equipment. Since QKD is hardware-based it also lacks flexibility for upgrades or security patches.

3. Quantum key distribution increases infrastructure costs and insider threat risks. QKD networks frequently necessitate the use of trusted relays, entailing additional cost for secure facilities and additional security risk from insider threats. This eliminates many use cases from consideration.

4. Securing and validating quantum key distribution is a significant challenge. The actual security provided by a QKD system is not the theoretical unconditional security from the laws of physics (as modeled and often suggested), but rather the more limited security that can be achieved by hardware and engineering designs. The tolerance for error in cryptographic security, however, is many orders of magnitude smaller than in most physical engineering scenarios making it very difficult to validate. The specific hardware used to perform QKD can introduce vulnerabilities, resulting in several well-publicized attacks on commercial QKD systems.²

5. Quantum key distribution increases the risk of denial of service. The sensitivity to an eavesdropper as the theoretical basis for QKD security claims also shows that denial of service is a significant risk for QKD.

 

Conclusion

In summary, NSA views quantum-resistant (or post-quantum) cryptography as a more cost effective and easily maintained solution than quantum key distribution. For all of these reasons, NSA does not support the usage of QKD or QC to protect communications in National Security Systems, and does not anticipate certifying or approving any QKD or QC security products for usage by NSS customers unless these limitations are overcome.

¹See csrc.nist.gov/Projects/post-quantum-cryptography
² See, for example:

• Vakhitov, Makarov, and Hjelme, Large pulse attack as a method of conventional optical eavesdropping in quantum cryptography, Journal of Modern Optics 48, 2001.

• Makarov and Hjelme, Faked states attack on quantum cryptosystems, Journal of Modern Optics, vol. 52, 2005.

• Ferenczi, Grangier, Grosshans, Calibration Attack and Defense in Continuous Variable Quantum Key Distribution, CLEO-IQEC, 2007.

• Zhao, Fung, Qi, Chen, and Lo, Experimental demonstration of time-shift attack against practical quantum key distribution systems, Physical Review A vol. 78, 2008.

• Scarani and Kurtsiefer, The black paper of quantum cryptography: Real implementation problems, Theoretical Computer Science (560) 2014.

In place of ordinary bits used by today’s computers, quantum computers use “qubits” that behave in surprising ways, efficiently performing certain mathematical algorithms exponentially faster than a classical computer. Small, laboratory-scale examples of quantum computers have been built.

Also written as “cryptographically relevant quantum computer,” CRQC describes quantum computers that are capable of attacking real world cryptographic systems. Whether the “C” indicates “cryptanalytically” or “cryptographically” is a matter of writer’s preference, as the two terms are essentially equivalent in this context.

A CRQC, if built, would be capable of undermining the widely deployed public-key algorithms currently used for asymmetric key exchanges and digital signatures with potentially devastating impact to systems. National security systems (NSS) use public-key cryptography as a critical component to protect the confidentiality, integrity, and authenticity of national security information.

“Quantum-resistant” (QR), “quantum-safe,” and “post-quantum” (PQ) cryptography are all terms used to describe cryptographic algorithms that can be run on computers today and are believed to be resistant to cryptanalytic attacks from both classical and quantum computers.

CNSA 2.0 is the suite of QR algorithms approved for eventual NSS use. The following table lists the algorithms and their functions, specifications, and parameters.
 

Algorithm	Function	Specification	Parameters
Advanced Encryption Standard (AES)	Symmetric block cipher used for information protection	FIPS PUB 197	Use 256-bit keys for all classification levels.
CRYSTALS-Kyber	Asymmetric algorithm used for key establishment	TBD	Use Level V parameters for all classification levels.
CRYSTALS-Dilithium	Asymmetric algorithm used for digital signatures	TBD	Use Level V parameters for all classification levels.
Secure Hash Algorithm (SHA)	Algorithm used for computing a condensed representation of information	FIPS PUB 180-4	Use SHA-384 or SHA-512 for all classification levels.
Leighton-Micali Signature (LMS)	Asymmetric algorithm used for digitally signing firmware and software	NIST SP 800-208	All parameters approved for all classification levels. SHA-256/192 recommended.
Xtended Merkle Signature Scheme (XMSS)	Asymmetric algorithm used for digitally signing firmware and software	NIST SP 800-208	All parameters approved for all classification levels.

CNSA 2.0 algorithms will be required for all products that employ public-standard algorithms in NSS, whether a future design or currently fielded. Any usage of Suite B or CNSA 1.0 algorithms will be required to transition to CNSA 2.0 usage. Timeframe information for transition is presented in the Timeframe section of this FAQ and in the Advisory Memorandum. More details will be forthcoming.

NSA chose algorithms approved by the National Institute of Standards and Technology (NIST) as NIST is the U.S. Government lead for commercial algorithm approval. In addition, the algorithms have passed NSA security evaluation criteria. NSA believes these algorithms offer optimal performance for given NSS security requirements.

NSA performed its own analysis of CNSA 2.0 algorithms and believes that they are appropriate for use in protecting U.S. NSS for the long term in their many and varied missions. NSA makes no specific claims regarding how these algorithms perform against specific security metrics.

NSA intends to provide implementation guidance for CNSA 2.0 algorithms. NSA has not determined where these guides will be published.

NSA makes CNSA 2.0 requirements, anticipated timing, and this related FAQ widely available to assist NSS owners and operators in their transition planning and to inform industry of NSS requirements. 

Even NSS systems that are in use will need to upgrade in a timely fashion unless the system has received a waiver through the approved process. This is in agreement with National Security Memorandums (NSMs) 8 and 10.

High-grade equipment will follow the guidance in CJCSN 6510[1] and CNSSAM 01-07-NSM[2]. Commercial equipment will follow CNSA 1.0 until the transition mandated by CNSSP 15[3]. This is expected to occur sometime between 2025 and 2030, depending on equipment type. In accordance with NSM-10, QR algorithms should only be implemented in mission systems when validated by the National Information Assurance Partnership (NIAP).

---

[1] Chairman of the Joint Chiefs of Staff Notice 6510, Information Assurance Cryptographic Device Modernization Requirements, August 2019.

[2] Committee on National Security Systems Advisory Memorandum 01-07-NSM, Cryptographic Equipment Modernization Planning, 20 March 2022.

[3] Committee on National Security Systems Policy 15, Use of Public Standards for Secure Information Sharing.

The CNSA Suite mandates symmetric algorithms with sufficient strength to resist anticipated quantum computing threats. The intent is to only update the public key components of the suite with quantum-resistant components./>

NIST standardized stateful hash-based signatures in NIST SP 800-208[1]. This standard also provides references to other technical documentation on the topic. NSA recommends using Federal Information Processing Standards (FIPS)-validated hash-based signatures to protect NSS in the specialized scenarios outlined in the standard—e.g., for firmware signing and software signing. NSA’s preferred parameter set is Section 4.2, LMS with SHA-256/192.

---

[1] NIST Special Publication 800-208, Recommendation for Stateful Hash-Based Signature Schemes.

The term “Suite B” had become associated with a specific, fixed set of algorithms rather than with the use of selected public algorithms to protect classified information. To avoid confusion, the term “Suite B” is no longer being used.

The reasons for choosing separate algorithms for software- and firmware-signing is three-fold:

• The algorithms are fully standardized today by NIST while other post-quantum signatures are not yet standardized,
• This signature use-case is more urgent,
• This selection places algorithms which have the most substantial history of cryptanalysis in a use case where their potential performance issues have minimal impact. In particular, this usage coincides well with the requirement for keeping track of state—that is, how many times a given public key has been used in signing software or firmware when deploying these signatures.

In many firmware-signing cases, the validation algorithm is not easily updated. Thus, firmware-signing algorithms are frequently locked in for the life of a system.

NIST announced they will standardize lattice-based KEMs and digital signatures. NIST’s post-quantum standardization page includes reports from previous rounds of the standardization effort. These reports include summaries of the cryptography under consideration and many references.

For NSS, NSA agrees with NIST: CRYSTALS-Dilithium is preferred, as Falcon seems more susceptible to implementation errors that may affect security. Since NIST intends to prioritize the standardization of CRYSTALS-Dilithium, it also will likely be available sooner.

SHA-384 remains approved in the newest CNSA Suite, as it is believed to provide sufficient security for NSS. Designers often prefer to use SHA-512 for performance reasons. This is supported; however, customers need to be certain that using SHA-512 does not lead to interoperability issues. Some cryptographic applications use truncated hash values or other NIST-approved hash functions as part of their design. NSA may provide protocol-specific guidance or customers may consult with NSA for clarification in these cases. However, using other hash algorithms is not generally approved. That being said, the new QR algorithms propose a SHA-3 variant as an internal part of the algorithm. NSA has no concerns about this but does not anticipate approving SHA-3 algorithms for general purpose use at this time.

Authorizing officials will be reporting regularly on adoption in accordance with NSM‑10. It is important that they use the tools and resources available to ensure that all systems that use cryptography for security (including software update mechanisms) implement CNSA 2.0 algorithms. Any deviations should be reported to NSA in accordance with NSM-10 processes.

NSA intends that all NSS will be quantum-resistant by 2035, in accordance with the goal espoused in NSM-10. NSA relies upon NIST-approved commercial cryptography for commercial solutions. After NIST has finalized the standards associated with CNSA 2.0, NSA will update CNSSP 15. New cryptographic developments will be required to support CNSA 2.0 algorithms as an option once appropriate standards for the given technology are in place, and all appropriate system components should be configured to prefer CNSA 2.0 algorithms. As products mature, those components should be configured to accept only CNSA 2.0 algorithms.

NSA will provide guidance and updated protection profiles as industry develops the appropriate standards since product lines may develop at different speeds. CNSA 1.0 algorithms will continue to be used until current solutions can operate in a CNSA 2.0 mode. NSA’s current view on timing is as follows:

• Software- and firmware-signing: begin transitioning immediately, support and prefer CNSA 2.0 by 2025, exclusively use CNSA 2.0 by 2030.
• Web browsers/servers and cloud services: support and prefer CNSA 2.0 by 2025, exclusively[1] use CNSA 2.0 by 2033.
• Traditional networking equipment (e.g., virtual private networks, routers): support and prefer CNSA 2.0 by 2026, exclusively use CNSA 2.0 by 2030.
• Operating systems: support and prefer CNSA 2.0 by 2027, exclusively use CNSA 2.0 by 2033.
• Niche equipment (e.g., constrained devices, large public-key infrastructure systems): support and prefer CNSA 2.0 by 2030, exclusively use CNSA 2.0 by 2033.
• Custom applications and legacy equipment: update or replace by 2033.

---

[1] Hybrid solutions may be allowed due to protocol standards, product availability, or interoperability requirements, but CNSA 2.0 algorithms will become mandatory to select at the given date, and selecting CNSA 1.0 algorithms alone will no longer be approved.

NIAP and the Commercial Solutions for Classified (CSfC) program will update their profiles and requirements in accordance with industry adoption. That being said, NSA intends an aggressive timeframe for adoption (see the bullets above) and requests industry support for it

As industry adopts CNSA 2.0 algorithms, NSA will require transition of fielded equipment to CNSA 2.0 as well. In some circumstances, this may require a hardware refresh. NSA encourages NSS owners and operators to plan for this.

This question is best answered by NIST. See NIST’s Post-Quantum Cryptography Standardization project page for more information.

IETF and other standards development organizations (SDO) are independent bodies. NSA hopes that RFCs and other SDO standards will soon be forthcoming with the appropriate level of security and implementation analysis that these important standards are due, and with the appropriate prioritization. NSA encourages CNSA 2.0 to be adopted in standards and to be deployed in vendor products.

AES-256, SHA-384, SHA-512, and the NIST hash-based signatures listed in NIST SP 800-208 are believed to be safe against attack by a large quantum computer. Developers should deploy these algorithms today. They should also begin implementing the other quantum-resistant algorithms that NIST and NSA have chosen and provide feedback about any issues discovered. NSS owners and operators should test implementations of algorithms in lab networks to prepare for the transition.

The CNSA 1.0 Suite continues to represent the interim strategy as the commercial space transitions to the algorithms in CNSA 2.0. Following forthcoming NSA guidance and NIST standardization efforts will best position NSS owners and operators to make this transition.

NSA encourages vendors to use the CNSA 2.0 approved hash-based signatures for software- and firmware-signing. NSA does not approve using pre-standardized or non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes) for NSS missions. However, NSA does recommend limited use of pre-standardized or non-FIPS-validated CNSA 2.0 algorithms and modules in research settings to prepare for the transition. NSA requests vendors begin preparing to implement CNSA 2.0 algorithms so they are prepared to provide products soon after NIST’s completion of standardization.

Committee on National Security Systems Policy 15 (CNSSP 15) specifies commercial cryptographic algorithms for use in protecting NSS, in conjunction with other CNSS- and NSA-documented processes. Originally, it specified “NSA Suite B,” but was then revised to specify the CNSA 1.0 Suite in CNSSP 15 Annex B. It will be revised again to include CNSA 2.0 algorithms as NIST completes standardizing the selections from Round 3 of the standardization process. Further details about CNSS can be found at www.cnss.gov.

The October 2016 update to CNSSP 15 made three significant changes. First, it replaced the previous requirement to transition systems to “Suite B” standards, specifying a larger selection of algorithms (i.e., CNSA) to allow extended use of existing solutions while post-quantum standards are developed. Second, it consolidated the two security levels of Suite B into a single set of requirements for use at all levels. Finally, while the previous version of CNSSP 15 was directed explicitly at classified information, the updated policy applies to all NSS, both classified and unclassified. NSA plans to update algorithms in CNSSP 15 with the CNSA 2.0 suite of algorithms as noted in the recent cybersecurity advisory, “Announcing the Commercial National Security Algorithm Suite 2.0,” and to deprecate CNSA 1.0 algorithms in the next version. NSA plans to keep the other previous changes as they are, having a single set of requirements for both unclassified and all levels of classified NSS.

CNSS Instruction 1253[1] mandates the use of the Risk Management Framework (RMF) as documented in NIST SP 800-39[2] and 800-53[3] in the management of National Security Information Systems. SP 800-53 includes security controls (e.g., SC-12) that relate to cryptography. For NSS, the “NSA Approved” selection is required. Unless otherwise stated by NSA, the “NSA Approved” cryptography selection should be understood to include the CNSA 1.0 algorithm requirements as well as all other relevant guidance from NSA on product validation and operation.

---

[1] Committee on National Security Systems Instruction 1253, Security Categorization and Control Selection for National Security Systems.

[2] NIST Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View.

[3] NIST Special Publication 800-53 Rev.5, Security and Privacy Controls for Information Systems and Organizations.

NSA establishes requirements for NSS. Often these systems require protection for long periods against targeted efforts conducted by sophisticated and well-resourced adversaries in potential wartime settings. NIST establishes cryptographic standards for other government systems. If there is uncertainty about whether a specific system is subject to the NSS requirements, contact NSA to assist in addressing the question. See also NIST SP 800-59[1].

---

[1] NIST Special Publication 800-59, Guideline for Identifying an Information System as a National Security System.

Many commercial protocols allow a pre-shared key option that may mitigate the quantum threat, and some allow the combination of pre-shared and asymmetric keys in the same negotiation. However, this issue can be complex. Customers who wish to explore this option should contact NSA or follow guidance provided by the CSfC program.

It is generally accepted that quantum computing techniques are much less effective against symmetric algorithms than against current widely used public-key algorithms. While public-key cryptography requires changes in the fundamental design, symmetric algorithms are believed to be secure, provided a sufficiently large key size is used. The CNSA 2.0 symmetric algorithms—which are essentially the same as the CNSA 1.0 symmetric algorithms—are quantum-resistant.

NSA does not know when a CRQC will exist. Expert assessments disagree significantly about timing. NSS often have very long lifecycles. NSA has to produce requirements today for systems that will be used for many decades in the future. Consequently, the data protected by these systems will still require cryptographic protection for decades after these systems are at end of life. There is growing research in the area of quantum computing, and enough progress is being made that NSA must act now to protect NSS by providing the requirements for the transition to CNSA 2.0.

The field of quantum cryptography involves specialized hardware that uses the physics of quantum mechanics to protect the confidentiality of sensitive information. The most common example today uses quantum physics to distribute keys for use in a traditional symmetric algorithm, and is thus known as “quantum key distribution” or QKD. This technology exists today and is distinct from the quantum computing technology that might one day be used to attack cryptographic algorithms. The sole function of QKD is to distribute keys between users. Hence, it is only one part of a cryptographic system.

No. The technology involved is of significant scientific interest, but it only addresses some security threats and it requires significant engineering modifications to NSS communications systems. NSA does not generally consider QKD a practical security solution for protecting NSS. NSS owners should not be using or researching QKD at this time without direct consultation with NSA. For specific questions, NSS owners can contact NSA.

Quantum random number generators are hardware random number generators that use specific quantum effects to generate nondeterministic randomness. The decision on which RNG is appropriate to use in a specific scenario depends on many factors. In addition, any properly certified/approved RNG should be acceptable if implemented within the constraints of that approval.

No, CNSSP 11 states that all commercial-off-the-shelf information assurance (IA) and IA-enabled information technology products acquired to protect information on NSS shall comply with the requirements of the NIAP program in accordance with NSA‑approved processes and, where applicable, the requirements of FIPS cryptographic validation programs. Furthermore, CNSSP 7 states that a CSfC solution that has been approved by the appropriate Authorizing Official and registered with NSA’s CSfC Program Management Office as being compliant with an NSA-provided Capability Package may be used to protect NSS.

Some CSfC solutions may be implemented today using symmetric, pre-shared keys that protect against the long-term quantum computing threat. NSA considers using pre-shared symmetric keys in a standards-compliant fashion to be a better near-term post quantum solution than implementing experimental post-quantum asymmetric algorithms that may not be compatible with NIST standards. Eventually, capability packages will be provided—in concert with commercial technological development—to implement CNSA 2.0 algorithms.

For details, contact the CSfC program office.

NSA is interested in learning of potential use cases for any of the innovative cryptography listed below (or other similar cryptographic innovation). CNSSP 15 mandates the use of public standards, while allowing exceptions for additional NSA-approved options when needed. Neither NSA nor NIST have produced standards for these areas, and NSA has not issued any general approval for using these technologies. Many of these topics involve novel security properties, which require further scrutiny. NSS owners should consult with NSA before any use of cryptography beyond that specified in CNSA 1.0 or CNSA 2.0 and other published guidance. In particular, there are no generally approved solutions for:

• Distributed ledgers or blockchains
• Private information retrieval (PIR)
• Private set intersection (PSI)
• Identity-based encryption (IBE)
• Attribute-based encryption (ABE)
• Homomorphic encryption (HE)
• Group signatures
• Ring signatures
• Searchable encryption

NSA has programs for certifying solutions built to protect classified information. This certification process applies to developments intended specifically for government use or control. NSA also participates in efforts such as NIAP and runs the Commercial Solutions for Classified program. These both require strict compliance to traditional cryptographic standards and designs. NSA does not accept direct requests from commercial vendors to validate their products or offer a general use vendor certification for novel cryptographic solutions. If an NSS customer believes they have a mission need to use cryptography beyond those in the existing programs, they should engage with NSA directly to discuss their unique situation.

A hybrid solution for a protocol is one that uses multiple algorithms instead of one to perform the same function, such as key agreement or authentication. The algorithms are used in such a way that an attacker must break each algorithm to compromise the security of a system. Hybrid solutions can consist of many traditional or QR algorithms. The individual algorithms used in a hybrid solution are called “component algorithms.”

NSA has confidence in CNSA 2.0 algorithms, and so, will not require NSS developers to use hybrid certified products for security purposes. Product availability and interoperability requirements may lead to adopting hybrid solutions. NSA recognizes that some standards may require using hybrid-like constructions to accommodate the larger sizes of CRQC algorithms and will work with industry on the best options for implementation.

Hybrids add complexity to protocols, as designers need to incorporate additional negotiation and error handling.
Hybrid deployments introduce additional interoperability concerns, as now all algorithms plus the method of hybridization must be common features of all parties to a communication.

Many hybrid solutions being developed externally do not facilitate the transition to strictly-QR solutions. This means that implementers would need to anticipate an additional significant transition from hybrid to QR as classical algorithms lose their utility.

Perhaps most importantly, hybrid solutions add additional complexity to implementations, so one must balance the risks of flaws in the increasingly complex implementation with the risk of a breakthrough in cryptanalysis.

Many security product failures occur due to implementation or configuration errors rather than failures in the underlying cryptographic algorithms. Therefore, spending limited resources to add cryptographic complexity can potentially weaken security.

In the cases where NSA supports hybrid solutions, extensive work will take place to ensure that implementations are compatible, are engineered to a high degree of robustness, and should facilitate a straightforward transition to QR-only solutions.

They should not be used on NSS mission systems; however, NSA encourages limited purchase and usage for research and planning purposes only to help prepare for the transition to the CNSA 2.0 Suite. NSA is confident that CNSA 2.0 algorithms will sufficiently protect NSS. Because of this, a hybrid solution is not required for security purposes. The use of non-standard solutions entails a significant risk of establishing incompatible solutions. Using a hybrid solution that involves a symmetric key in accordance with established standards (e.g., RFC 8446, RFC 8784) may be appropriate, but key management complexity generally restricts this to specialized applications.

For CSfC-specific questions customers should contact the Commercial Solutions for Classified Program Management Office at CSfC@nsa.gov.

Other specific questions from NSS users may be addressed via e-mail to NSACryptoToday@nsa.gov or through normal business channels.

Disclaimer of endorsement
The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose
This document was developed in furtherance of NSA’s cybersecurity missions, including its responsibilities to identify and disseminate threats to National Security Systems, Department of Defense, and Defense Industrial Base information systems, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact
Cybersecurity Report Inquiries and Feedback: CybersecurityReports@nsa.gov
Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov
Media Inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov