TLS Working Group Ari Singer INTERNET-DRAFT NTRU Cryptosystems Expires: January 3, 2002 July 3, 2001 NTRU Cipher Suites for TLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Abstract This document defines a group of new TLS cipher suites that utilize the NTRU encryption algorithm and the NSS signature algorithm. These cipher suites are designed to maximize computational efficiency on both the client and server sides and ease deployment of the TLS protocol on constrained and embedded devices. The document assumes the reader is familiar with the TLS protocol. Table of Contents Status of this Memo................................................1 Conventions used in this document..................................1 Abstract...........................................................1 1. Overview........................................................3 2. NTRU Key Exchange Algorithms....................................3 Singer INTERNET DRAFT - Expires January 2002 [Page 1] NTRU Cipher Suites for TLS July 2001 2.1 NTRU_NSS.......................................................4 2.2 NTRU_RSA.......................................................4 3. NTRU Client Authentication......................................5 3.1 nss_sign.......................................................5 3.2 rsa_nss........................................................5 4. Message Structures..............................................6 4.1 Server Certificate.............................................6 4.2 Server Certificate Request.....................................7 4.3 Client Certificate.............................................8 4.4 Client Key Exchange............................................8 4.5 Client Certificate Verify......................................9 5. Cryptographic Computations and Encoding........................10 5.1 NSS Digital Signing...........................................11 5.2 NSS Signature Verification....................................11 5.3 NTRU Encryption...............................................12 5.4 NTRU Decryption...............................................12 6. Cipher Suites..................................................13 7. Security Considerations........................................13 8. Intellectual Property Rights...................................13 9. References.....................................................15 Authors' Addresses................................................15 Singer INTERNET DRAFT - Expires January 2002 [Page 2] NTRU Cipher Suites for TLS July 2001 1. Overview The TLS protocol was designed with the purpose of enabling private and authenticated communication over the Internet, typically between high bandwidth and computationally rich entities. This goal is achieved through the use of a combination of public-key techniques, which provide authentication and key agreement between two parties that may not have a-priori knowledge of each other, and symmetric key techniques, which provide data privacy, continued authentication and efficiencies in bandwidth and computational effort. The purpose of this document is to specify new cipher suites that significantly reduce the computational cost of public-key operations and that are easy to implement on constrained devices. In practice, the computational cost of the public-key computations in TLS causes the most latency in the handshake and is often the limiting factor for server capacity of running multiple TLS sessions at once. In addition, TLS, especially with client authentication, may be difficult to implement on wireless devices and other constrained devices due to memory and computational limitations. The use of the NTRU encryption algorithm in the TLS handshake and the use of the NSS signature algorithm in the handshake and digital certificates may allow for greater server scalability, decreased latency in the handshake and deployment of the TLS protocol on a larger population of devices. This document specifies only cipher suites and the aspects of the TLS protocol that need to be modified in order to implement the cipher suites. No other changes to the TLS protocol are required. For use of this Internet Draft, familiarity with the TLS protocol is assumed. For full details of the TLS protocol, see RFC 2246 [RFC2246]. In this document, the terms Client Hello, Server Hello and Client Response refer to the grouping of consecutive messages sent in the initial handshake by either the server or client. The terms ClientHello, ServerKeyExchange, etc. refer to the specific messages defined in the TLS specification [RFC2246]. 2. NTRU Key Exchange Algorithms This document defines two new key exchange algorithms based on NTRU for use within TLS. These algorithms all utilize the NTRU encryption algorithm, but utilize different authentication mechanisms. The key exchange algorithms are as follows: Key Exchange Algorithm Description NTRU_NSS NTRU encryption with NSS signatures NTRU_RSA NTRU encryption with RSA signatures Singer INTERNET DRAFT - Expires January 2002 [Page 3] NTRU Cipher Suites for TLS July 2001 In both of the above key exchange algorithms, the server SHALL send an X.509 certificate in the Certificate field that is included in the Server Hello. This certificate SHALL contain an NTRU public key and be signed with the specified signature algorithm. The client SHALL verify that the certificate is valid and, if it is valid, generate a pre-master secret and encrypt it with the server public key. After successful verification of the server certificate, the client SHALL send the encrypted pre-master secret in the ClientKeyExchange field that is included in the Client Response. If the server desires for the client to be authenticated, the server MAY request a client certificate. Client certificate types for client authentication are defined in this document and specified in section 3. The key strength of the NTRU public key determines the size of the pre-master secret. The following table shows the required sizes of the pre-master secret with the corresponding NTRU key strength. NTRU 251, 347 and 503 provide roughly equivalent security to RSA 1024, RSA 2048 and RSA 4096 respectively. Key Strength Pre-master Secret Size NTRU 251 20 Bytes NTRU 347 32 Bytes NTRU 503 48 Bytes 2.1 NTRU_NSS For key exchanges using NTRU encryption with NSS signatures, the server certificate SHALL be an X.509 certificate that includes an NTRU public key and is signed by the NSS signature algorithm. The basic X.509 certificate structure may be found in RFC 2459 [RFC2459] and the ASN.1 syntax for NTRU public keys and NSS digital signatures may be found in Efficient Embedded Security Standard (EESS) #1 [EESS#1]. The NSS signature verification on the certificate and the NTRU encryption and decryption of the pre-master secret SHALL be performed as specified in EESS #1 [EESS#1]. The exact data structure for NTRU and NSS public keys, NTRU encrypted data and NSS signatures are defined in EESS #1 [EESS#1] and explicitly specified in section 4. 2.2 NTRU_RSA For key exchanges using NTRU encryption with RSA signatures, the server certificate SHALL be an X.509 certificate that includes an NTRU public key and is signed using the RSA signature algorithm. The approved methods for computing and verifying RSA signatures are listed in RFC 2246 [RFC2246], which references PKCS #1 [PKCS1]. The NTRU encryption and decryption of the pre-master secret SHALL be performed as specified in EESS #1 [EESS#1]. The data structures for RSA signatures are specified in RFC 2246 [RFC2246], which references Singer INTERNET DRAFT - Expires January 2002 [Page 4] NTRU Cipher Suites for TLS July 2001 PKCS #1 [PKCS1]. The exact data structure for NTRU public keys and NTRU encrypted data are defined in EESS #1 [EESS#1] and explicitly specified in section 4. 3. NTRU Client Authentication This document defines two new methods of client authentication based on NTRU for the TLS protocol. Both techniques utilize the NSS signature algorithm and the certificates MAY be signed using either RSA or NSS. If client authentication is desired during a TLS handshake, the client MAY present a certificate in either of the formats defined below or in any format permitted by RFC 2246 [RFC2246]. The client authentication mechanisms are as follows: Client Certificate Type Description nss_sign NSS signature key certificate signed by NSS rsa_nss NSS signature key certificate signed by RSA During the initial handshake between the server and client, the server MAY send a certificate request. The certificate request SHALL include an indication of the types of certificates that the server accepts and the certificate authorities that the server trusts. When a client certificate is requested by the server, if an appropriate certificate is available, the client SHALL include a client certificate in the Certificate field of the Client Response. In addition, the client SHALL include a digital signature of the handshake messages in the CertificateVerify field of the Client Response. 3.1 nss_sign For client authentication using NSS signatures, the client certificate SHALL be an X.509 certificate that includes an NSS public key and is signed by the NSS signature algorithm. The ASN.1 syntax for NSS public keys and NSS digital signatures may be found in EESS #1 [EESS#1]. The NSS signature generation on the handshake messages and the NSS signature verification of the certificate and handshake messages SHALL be performed as specified in EESS #1 [EESS#1]. The exact data structure for NSS public keys and NSS signatures are defined in EESS #1 [EESS#1] and explicitly specified in section 4. 3.2 rsa_nss For client authentication using NSS signatures and RSA signed certificates, the client certificate SHALL be an X.509 certificate Singer INTERNET DRAFT - Expires January 2002 [Page 5] NTRU Cipher Suites for TLS July 2001 that includes an NSS public key and is signed using the RSA signature algorithm. The approved methods for computing and verifying RSA signatures are listed in RFC 2246 [RFC2246], which references PKCS #1 [PKCS1]. The NSS signature and verification of the handshake messages SHALL be performed as specified in EESS #1 [EESS#1]. The data structures for RSA signatures are specified in RFC 2246 [RFC2246], which references PKCS #1 [PKCS1]. The exact data structure for NSS public keys and NSS signatures are defined in EESS #1 [EESS#1] and explicitly specified in section 4. 4. Message Structures This section defines the specific message data structures necessary for implementation of the TLS protocol using the NTRU and NSS cryptographic algorithms. These definitions should be taken within the context of the TLS protocol as defined in RFC 2246 [RFC2246] and used where appropriate. The naming conventions for the specific fields are consistent with RFC 2246 [RFC2246]. The cryptographic computations and encoding of NTRU and NSS cryptographic data items are specified in section 5. The following data structures are defined in this section: Data Structure Description Server Certificate The signed data structure that is sent during the Server Hello for server authentication and key exchange. Server Certificate Request The data structure that is used to request a client certificate for client authentication. Client Certificate The signed data structure that is sent during the Client Response for client authentication. Client Key Exchange The data structure that includes the encrypted pre-master secret for the upcoming secure session. Client Certificate Verify The signature that is sent during the Client Response that authenticates the client for that handshake. 4.1 Server Certificate When this message will be sent: In all non-anonymous TLS handshakes, the server sends a server certificate to the client during the Server Hello. This message will always immediately follow the ServerHello message. Meaning of this message: The certificate type SHALL be appropriate for the selected cipher suite's key exchange algorithm and is generally an X.509v3 certificate. The public key may be of any length. The Singer INTERNET DRAFT - Expires January 2002 [Page 6] NTRU Cipher Suites for TLS July 2001 certificate is used to authenticate the server to the client and provide the encryption key for key exchange. Key Exchange Algorithm Certificate Key Type NTRU_NSS NTRU encryption key; the certificate SHALL allow the key to be used for encryption. The algorithm used to sign the certificate SHALL be NSS. NTRU_RSA NTRU encryption key; the certificate SHALL allow the key to be used for encryption. The algorithm used to sign the certificate SHALL be RSA. The certificate profiles are defined by the IETF PKIX working group [RFC2459]. NTRU and NSS key and cryptographic formats are defined by the CEES [EESS#1]. RSA key and cryptographic formats are defined by PKCS #1 [PKCS#1]. When a key usage extension is present, the keyEncipherment bit must be present to allow encryption. Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence of X.509v3 certificates as specified in RFC 2246 [RFC2246] except that the key, signature and parameter fields for NTRU and NSS are as specified in EESS #1 [EESS#1]. 4.2 Server Certificate Request When this message will be sent: A non-anonymous server MAY request a certificate from the client if client authentication is desired. This message, if sent, SHALL be sent in the Server Hello immediately following the ServerKeyExchange message, if it is sent, or the Server Certificate message. Meaning of this message: This message informs the client that the server requests the use of a client certificate. It informs the client of the types of certificate accepted by the server and Structure of this message: For consistency with draft-ietf-tls-ecc-01.txt, the TLS CertificateRequest message is extended as follows: enum { nss_sign (8), nss_rsa (9), (255) } ClientCertificateType; nss_sign Singer INTERNET DRAFT - Expires January 2002 [Page 7] NTRU Cipher Suites for TLS July 2001 The server requests a client certificate that contains an NSS key and is signed by an NSS signature. rsa_nss The server requests a client certificate that contains an NSS key and is signed by an RSA signature. 4.3 Client Certificate When this message will be sent: If the server has requested a client certificate and the client wishes to send a certificate to the server, the client MAY send a Client Certificate message. This message, if sent, SHALL be the first message in the Client Response. Meaning of this message: The certificate type SHOULD be selected among the certificate types requested by the server and is generally an X.509v3 certificate. The public key may be of any length. The certificate is used to authenticate the client to the server. The certificate profiles are defined by the IETF PKIX working group [RFC2459]. NSS keys and cryptographic formats are defined by the CEES [EESS#1]. RSA keys and cryptographic formats are defined by PKCS #1 [PKCS#1]. When a key usage extension is present, the digitalSignature bit must be set for the key to be eligible for signing. Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence of X.509v3 certificates as specified in RFC 2246 [RFC2246] except that the key, signature and parameter fields for NTRU and NSS are as specified in EESS #1 [EESS#1]. 4.4 Client Key Exchange When this message will be sent: This message is always sent in the Client Response. It SHALL immediately follow the client certificate message, if it is sent. Otherwise, it SHALL be the first message in the Client Response. Meaning of this message: This message contains the NTRU encrypted pre-master secret. The pre-master secret is used in TLS along with the other data to calculate the master secret. Depending on the NTRU key size, the pre-master secret will have different sizes. For the Singer INTERNET DRAFT - Expires January 2002 [Page 8] NTRU Cipher Suites for TLS July 2001 table of permitted key sizes and pre-master secret sizes, see section 2. Structure of this message: The structure of the message depends on the selected key exchange method. The KeyExchangeAlgorithm and ClientKeyExchange from RFC 2246 [RFC2246] are extended to include NTRU. NOTE: The operation public-key-encrypted is defined in RFC 2246 [RFC2246] section 4.7 and specifies that the length is represented as an opaque vector <0..2^16-1>, where the length is specified by the encryption algorithm (e.g. NTRU) and key. enum { ntru } KeyExchangeAlgorithm; ntru The KeyExchangeAlgorithm message contains an NTRU public key. struct { select (KeyExchangeAlgorithm) { case ntru: NTRUEncryptedPreMasterSecret; } exchange_keys; } ClientKeyExchange enum { NTRU251 (1), NTRU347 (2), NTRU503 (3), (255) } NTRUKeyStrength NTRU251, NTRU347, NTRU503 The number in the NTRU key strength name represents the size of the NTRU degree N (e.g. NTRU251 has degree N equal to 251). select (NTRUKeyStrength) { case NTRU251: opaque random [20]; case NTRU347: opaque random [32]; case NTRU503: opaque random [48]; } PreMasterSecret random The random variable is a securely generated random value to be used as the pre-master secret. struct { public-key-encrypted PreMasterSecret pre_master_secret; } NTRUEncryptedPreMasterSecret; pre_master_secret The value of the pre-master secret, which is encrypted with the NTRU encryption key provided by the server to obtain the NTRUEncryptedPreMasterSecret. 4.5 Client Certificate Verify When this message will be sent: Singer INTERNET DRAFT - Expires January 2002 [Page 9] NTRU Cipher Suites for TLS July 2001 This message SHALL only be sent following a client certificate that contains a key that has singing capability (e.g. an NSS signing key). When sent, it SHALL immediately follow the client key exchange message in the Client Response. Meaning of this message: This message is the digital signature of all of the preceding handshake messages and is used to provide explicit verification of a client certificate. Structure of this message: The SignatureAlgorithm and Signature from RFC 2246 [RFC2246] are extended to include NSS. NOTE: The operation digitally-signed is defined in RFC 2246 [RFC2246] section 4.7 and specifies that the length is represented as an opaque vector <0..2^16-1>, where the length is specified by the signature algorithm (e.g. NSS) and key. enum { nss } SignatureAlgorithm; select (SignatureAlgorithm) { case nss: digitally-signed struct { opaque sha_hash[20]; }; } Signature; sha_hash This is the SHA-1 hash of all of the preceding handshake messages. The SHA-1 algorithm is defined in FIPS 180-1 [FIPS180-1]. struct { Signature signature; } CertificateVerify; 5. Cryptographic Computations and Encoding This section specifies the exact cryptographic computations and encoding of NTRU and NSS data structures that are needed in order to implement TLS with the NTRU and NSS cipher suites. When not explicitly stated, all cryptographic encoding and computations SHALL be as specified in RFC 2246 [RFC2246]. Note that in particular, RSA signature verification on certificates SHALL be computed as specified in RFC 2246 [RFC2246]. The following cryptographic computations and descriptions of their use in TLS are defined in this section. Computation Description NSS Digital Signing The operation of computing the NSS digital signature on the specified hash Singer INTERNET DRAFT - Expires January 2002 [Page 10] NTRU Cipher Suites for TLS July 2001 value and encoding the signature as an opaque object. NSS Signature Verification The operation of verifying an NSS digital signature on a certificate or on the handshake messages. NTRU Encryption The operation of computing the NTRU encryption of the pre-master secret and encoding the encrypted data as an opaque object. NTRU Decryption The operation of decrypting the pre- master secret. 5.1 NSS Digital Signing When this operation is performed: Whenever client authentication is performed, the client generates an NSS digital signature on all of the preceding handshake messages and places this signature in the CertificateVerify message in the Client Response. NSS digital signatures on certificates are outside of the scope of TLS, however, it is assumed that the NSS certificate signatures are performed as specified by the SVSSA signature scheme as defined in EESS #1 [EESS#1] and encoded in the certificate according to EESS #1 [EESS#1]. Operation: For all NSS digital signature operations in this document, the signature SHALL be performed as specified by the SVSSA signature scheme as defined in EESS #1 [EESS#1]. The parameter values SHALL be included in the client certificate and SHALL be interpreted according to EESS #1 [EESS#1]. For the ClientVerify message, the input to the signature scheme SHALL be the concatenation of all of the previous handshake messages and the hash function for creating the hash of the message SHALL be SHA-1 [FIPS180-1] and SHALL NOT be MD5. Encoding: The structure of NSS signatures, written in TLS as the function digitally-signed, SHALL be encoded as a type 1 vector as defined in EESS #1 [EESS#1]. (This is essentially the polynomial written as a byte string of coefficients ordered from lowest degree to highest, with each byte representing a single coefficient.) 5.2 NSS Signature Verification When this operation is performed: The client performs NSS signature verification to verify the server certificate in all NTRU cipher suites. The server performs NSS signature verification in all client authenticated handshakes to verify the client certificate and to verify the ClientVerify message. Singer INTERNET DRAFT - Expires January 2002 [Page 11] NTRU Cipher Suites for TLS July 2001 Operation: For all NSS verification operations in this document, the verification SHALL be performed as specified by the SVSSA signature scheme as defined in EESS #1 [EESS#1]. The server SHALL verify that the parameter values be included in the client certificate and interpret them according to EESS #1 [EESS#1]. For the ClientVerify message verification, the input to the verification process SHALL be the concatenation of all of the previous handshake messages and the hash function for creating the hash of the message SHALL be SHA-1 [FIPS180-1] and SHALL NOT be MD5. If all of the above checks pass, the server SHALL accept the signature as valid, otherwise the server SHALL reject the signature as invalid. 5.3 NTRU Encryption When this operation is performed: The client performs NTRU encryption on the pre-master secret in all cipher suites defined in this document. The encrypted pre- master secret is included in the ClientKeyExchange message in the Client Response. Operation: For all NTRU encryption operations in this document, the encryption SHALL be performed as specified by the SVES encryption scheme as defined in EESS #1 [EESS#1]. The parameter values SHALL be included in the server certificate (or ServerKeyExchange message) and SHALL be interpreted according to EESS #1 [EESS#1]. For the ClientKeyExchange message, the input to the encryption scheme SHALL be the pre- master secret as the leftmost (first) bytes, padded on the right (end) by any byte string that makes the total length equal to the input length of the encryption function (e.g. for NTRU 251, the 20-byte pre-master secret will be padded with 1 byte on the right to obtain a 21-byte input to the encryption function). The padding SHOULD consist of all '0' bytes. Encoding: The structure of NTRU encryptions, written in TLS as the function public-key-encrypted, SHALL be encoded as a type 1 vector as defined in EESS #1 [EESS#1]. (This is essentially the polynomial written as a byte string of coefficients ordered from lowest degree to highest (left to right), with each byte representing a single coefficient.) 5.4 NTRU Decryption When this operation is performed: The server performs NTRU decryption on the encrypted pre-master secret in all cipher suites defined in this document. The encrypted pre-master secret is included in the ClientKeyExchange message in the Client Response. Operation: Singer INTERNET DRAFT - Expires January 2002 [Page 12] NTRU Cipher Suites for TLS July 2001 For all NTRU decryption operations in this document, the decryption SHALL be performed as specified by the SVES encryption scheme as defined in EESS #1 [EESS#1]. The server SHALL use the parameter values that are included in the server certificate and interpret them according to EESS #1 [EESS#1]. For the decryption of the pre-master secret, the input to the decryption process SHALL be the encrypted pre-master secret included in the ClientKeyExchange message. The output of the NTRU decryption operation SHALL be truncated to obtain the pre- master secret by taking the leftmost (first) n bytes of the plaintext, where n is the length of the pre-master secret. 6. Cipher Suites The table below defines the cipher suites specified in this document. They are interpreted according to their names in the same manner as in RFC 2246 [RFC2246]. The key agreement methods specified in this standard are NTRU_NSS and NTRU_RSA. The cipher suite numbers are subject to change depending on the numbering conventions and the numbers that are already used. CipherSuite TLS_NTRU_NSS_WITH_RC4_128_SHA = { 0x00, 0x61 } CipherSuite TLS_NTRU_NSS_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x62 } CipherSuite TLS_NTRU_NSS_WITH_AES_128_CBC_SHA = { 0x00, 0x63 } CipherSuite TLS_NTRU_NSS_WITH_AES_256_CBC_SHA = { 0x00, 0x64 } CipherSuite TLS_NTRU_RSA_WITH_RC4_128_SHA = { 0x00, 0x65 } CipherSuite TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x66 } CipherSuite TLS_NTRU_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x67 } CipherSuite TLS_NTRU_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x68 } Ciphers other than AES ciphers and hash algorithms are specified in RFC 2246 [RFC2246]. AES ciphers are specified in [TLS-AES]. Implementations supporting NTRU cipher suites SHOULD support the following cipher suite. Implementations MAY support any of the other cipher suites. TLS_NTRU_NSS_WITH_AES_128_CBC_SHA 7. Security Considerations This document is entirely concerned with security mechanisms. It is based on the TLS specification [RFC 2246], IEEE P1363.1 [P1363.1] and EESS #1 [EESS#1] and the appropriate security considerations from those documents apply. 8. Intellectual Property Rights NTRU Cryptosystems, Inc. has been granted U.S. Patent No. 6,081,597, which covers aspects of the NTRU public-key encryption scheme, and has applied for a patent (or patents) that covers the NSS public-key signature scheme. In addition, NTRU Cryptosystems may have applied for additional patent coverage on implementation techniques related Singer INTERNET DRAFT - Expires January 2002 [Page 13] NTRU Cipher Suites for TLS July 2001 to the use of NTRU or NSS. This and any additional patent information will be sent to the IETF. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to implement the techniques in this document. Please address the information to the IETF Executive Director. Singer INTERNET DRAFT - Expires January 2002 [Page 14] NTRU Cipher Suites for TLS July 2001 9. References [EESS#1] Efficient Embedded Security Standards (EESS) #1: Implementation Aspects of NTRU and NSS, Draft Version 2, May 18, 2001, Consortium for Efficient Embedded Security Standards, Available at http://www.ceesstandards.org. [FIPS180-1] FIPS PUB 180-1, Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. Department of Commerce/National Institute of Standards and Technology, National Technical Information Service, Springfield, Virginia, April 17, 1995 (supersedes FIPS PUB 180). Available at http://www.itl.nist.gov/div897/pubs/fip180-1.htm. [P1363.1] IEEE Draft Standard P1363.1 D2: IEEE Standard Specifications for Public-Key Cryptographic Techniques Based on Hard Problems over Lattices, Draft 2, May 2001, Available at http://grouper.ieee.org/groups/1363. [PKCS#1] RSA Laboratories. RSA Encryption Standard. Version 2.0, October 1, 1998. [RFC2026] S. Bradner, "The Internet Standards Process", IETF RFC 2026, October 1996 [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", IETF RFC 2119, March 1997 [RFC2246] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0," IETF RFC 2246, January 1999 [RFC2459] R. Housley, W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", IETF RFC 2459, January 1999 [TLS-AES] P. Chown, "AES Ciphersuites for TLS", draft-ietf-tls- ciphersuite-03.txt, January 22, 2001 Authors' Addresses Ari Singer NTRU 5 Burlington Woods Phone: 1-781-418-2515 Burlington, MA 01803, USA Email: asinger@ntru.com Singer INTERNET DRAFT - Expires January 2002 [Page 15]