12 November 2013. Revised Cryptome mirror URL for Technical Requirements Document.
19 August 2006. A sends "NSA Encryption Algorithms:"
17 August 2006. An original .DOC version (3.8MB), dated 1/1/2006 is available, with figures [now dead]:
Cryptome mirror converted to PDF: http://cryptome.org/technical-requirements-document.pdf
See also related documents:
15 August 2006
Information invited on these algorithms cited in the document (send to: ):
Figures were not included with the cached document. Irregular paragraph numbering in the Google HTML conversion from DOC.
DOCUMENT DISTRIBUTION RESTRICTIONS:
This document contains information exempt from mandatory disclosure under the Freedom of Information Act (FOIA). Exemption 3 applies.
Not Releasable to the Defense Technical Information Center (DTIC) per DOD Instruction 3200.12.
Unclassified FOUO Information: The document contains unclassified For Official Use Only information which is for the exclusive use of Government and Contractor personnel with a need-to-know the information. Such information is specifically prohibited from posting on unrestricted bulletin boards or other unlimited access applications.
(U) Revision History
(U) TABLE OF CONTENTS
(U) List of Figures
(U) List of Tables
(U) The Programmable Objective Encryption
Technologies (POET) program will design and develop an Advanced Cryptographic
Module (ACM) capable of meeting the communications security needs outlined
below. This document provides the technical requirements of the POET
(U) Future terminal architectures will
require enhanced high-speed cryptographic capabilities in order to support
the higher data rates and increased information security (INFOSEC) demands
imposed by modern waveforms and ever-increasing security regulations.
(U) These future terminals are envisioned
to be a family of multi-band, multi-mode, transportable, modular, flexible,
Software Communications Architecture (SCA) compliant, satellite and Line
of Sight (LOS) systems supporting simultaneous communications between ground,
airborne and surface/subsurface units for a range of missions across all
services in tactical operational environments.
(U) These terminals will be capable
of operating with the military and commercial satellites, envisioned to be
operational in the 2010 and beyond timeframe, utilizing X, Ku, Ka, and Q-band
frequencies (above 2 GHz). These systems include, but are not limited to,
the Wideband Gapfiller System (WGS), Advanced Extremely High Frequency (AEHF),
Global Broadcast System (GBS) and Transformational Satellite Communications
System (TSAT) constellations. Commercial satellite support will include both
Ku and Ka-band systems. The terminals will also provide high-capacity
line-of-sight (LOS) communications utilizing Common Data Link (CDL) / Networked
Common Data Link (N-CDL) links or future variations thereof.
(U) Because the family of terminal
systems will operate with many legacy waveforms currently used by military
and civilian agencies and incorporate new waveforms as they are developed,
the cryptographic components of the terminal system will need to be programmable
and scaleable to meet specific user operational needs. The desire is that
the cryptographic capability provides flexibility through an open system
architecture that enables technology insertion (via re-programmability or
other means). The terminal system will be capable of high data throughput
rates per Radio Frequency (RF) channel; incremental RF channel expansion;
high levels of reliability, availability, and maintainability; technological
enhancement; and commercial support service compatibility.
(U) The emphasis of the initial POET development will be to mitigate the risks to the terminal developments by establishing a flexible and scalable cryptographic capability for which the long lead time development and certification efforts are already complete. The emphasis is not to develop a particular Âone size fits allÂ cryptographic product, but rather a capability that can be reused, scaled, and/or repackaged to satisfy the particular constraints of the different terminal developments. Achieving NSA certification of the POET Engineering Development Models (EDMs) is considered an important aspect of mitigating the risks to the terminal developments.
(U) POET ACM flexibility is important
due to the wide range of applications envisioned for these future terminals,
which may differ significantly in their mission applications and their size
weight and power (SWAP) requirements. In turn, the performance capabilities
and the SWAP requirements to be imposed on the ACM may vary significantly.
For example, a man-pack embedment would likely trade-off some
multi-band/multi-channel capability and data rate capacity in return for
a more stringent SWAP. In this case, an ACM might be required to support
two RF channels at lower data rates. Fixed terminals will likely require
the maximum functionality and capabilities and ACM embedments will be capable
of utilizing the increased SWAP available. Therefore, flexibility, modularity,
and scalability of design and architecture are necessary for the ACM.
(U) It is also anticipated that the
ACM will be used in terminals with different INFOSEC architectures. Some
terminals are expected to implement a ÂRED coreÂ
terminal architecture while other terminals are expected to implement a
ÂREDÂ terminal architecture. A RED core terminal
is defined as a terminal that may internally process classified information
as required by one or more waveforms, but for which all external interfaces
are unclassified. External interfaces include baseband Input/Output (I/O)
interfaces, locally connected operator interfaces, and RF interfaces. A RED
core terminal is capable of unattended operation in the ground tactical
environment. A RED terminal is defined as a terminal that may internally
process classified information and may also support classified external
interfaces. A RED terminal is not capable of unattended operation in the
ground tactical environment.
(U) A notional ÂRED coreÂ terminal architecture with embedded ACM is depicted in Figure 1-1. A RED core terminal with an embedded ACM will:
(U) A notional ÂREDÂ terminal architecture with embedded ACM is depicted in Figure 1-2. A RED terminal with an embedded ACM will:
Figure 1-2. (U) Notional Red Terminal Block Diagram
(U) The following paragraphs provide
definitions for terminology that is used in the remainder of this TRD. These
terms are defined here to promote uniform understanding of the requirements
for the ACM.
(U) Encryption Â The process
of converting Plaintext into Ciphertext by means of a code or cryptographic
(U) Decryption Â The process
of converting Ciphertext into Plaintext by means of a code or cryptographic
(U) Plaintext Â Unencrypted
(U) Ciphertext Â Encrypted
(U) Cryptographic Algorithm Â
Well-defined procedure or sequence of rules or steps, or a series of mathematical
equations used to describe cryptographic processes such as encryption/decryption,
key generation, authentication, signatures, etc.
(U) RED interface Â An
interface on which plaintext may enter or emerge from the
(U) BLACK interface Â An
interface on which unclassified plaintext and/or ciphertext may enter or
emerge from the ACM.
(U) RED Â Pertaining to
(U) BLACK Â Pertaining
to unclassified and/or ciphertext.
(U) RED Core Terminal Â A terminal that may internally process classified information as required by one or more waveforms/applications, but for which all external interfaces are unclassified. A RED Core terminal implies a terminal with the following attributes:
(U) RED Terminal Â A terminal
that may internally process classified information and may also support
classified external interfaces.
(U) COMSEC Â Acronym for ÂCommunications Secur