Recommendation for Key Management Part 3:
                                        Application-Specific Key Management Guidance

Barker, Elaine B.; Dang, Quynh H.

doi:10.6028/nist.sp.800-57pt3r1

Cited by 41 publications

(32 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The National Institute of Standards and Technology (NIST), that issues guidelines for the US federal government, disallows use of 1024-bit keys beyond 2014 [6]. But that NIST makes an exemption for DNSSEC until October 2015 "due to message size constraints [fragmentation]" is telling ( [7], §8.1.3).…”

Section: Rsa: the Root Cause?mentioning

confidence: 99%

See 1 more Smart Citation

Making the Case for Elliptic Curves in DNSSEC

Rijswijk-Deij

Sperotto

Pras

2015

SIGCOMM Comput. Commun. Rev.

View full text Add to dashboard Cite

The Domain Name System Security Extensions (DNSSEC) add authenticity and integrity to the DNS, improving its security. Unfortunately, DNSSEC is not without problems. DNSSEC adds digital signatures to the DNS, significantly increasing the size of DNS responses. This means DNS-SEC is more susceptible to packet fragmentation and makes DNSSEC an attractive vector to abuse in amplificationbased denial-of-service attacks. Additionally, key management policies are often complex. This makes DNSSEC fragile and leads to operational failures. In this paper, we argue that the choice for RSA as default cryptosystem in DNS-SEC is a major factor in these three problems. Alternative cryptosystems, based on elliptic curve cryptography (EC-DSA and EdDSA), exist but are rarely used in DNSSEC. We show that these are highly attractive for use in DNS-SEC, although they also have disadvantages. To address these, we have initiated research that aims to investigate the viability of deploying ECC at a large scale in DNSSEC.

show abstract

Section: Rsa: the Root Cause?mentioning

confidence: 99%

“…The table lists the number of times verification under the ECC scheme is slower than the RSA scheme. Values are based on the arithmetic average over the median number of CPU cycles for four recent CPU types7 . Tab.…”

mentioning

confidence: 99%

Making the Case for Elliptic Curves in DNSSEC

Rijswijk-Deij

Sperotto

Pras

2015

SIGCOMM Comput. Commun. Rev.

View full text Add to dashboard Cite

show abstract

“…The FIPS 140 validation certificate for the cryptographic module used by the server shall indicate that the random bit generator (RBG) has been validated in accordance with the SP 800-90 series [8,48,66]. 22 The server random value, sent in the ServerHello message, contains a 4-byte timestamp 23 value and 28-byte random value in TLS versions 1.0, 1.1, and 1.2, and contains a 32-byte random value in TLS 1.3. The validated random number generator shall be used to generate the random bytes of the server random value.…”

Section: Validated Cryptographymentioning

confidence: 99%

“…For example, the Heartbleed bug [70] was a flaw in an implementation of the heartbeat extension [64]. Although the extension has no 22 Validation will include compliance with SP 800-90C once it is available. 23 The timestamp value does not need to be correct in TLS.…”

Section: Tls Extension Supportmentioning

confidence: 99%

Guidelines for the selection, configuration, and use of Transport Layer Security (TLS) implementations

McKay¹,

Cooper²

2019

View full text Add to dashboard Cite

AuthorityThis publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. AbstractTransport Layer Security (TLS) provides mechanisms to protect data during electronic dissemination across the Internet. This Special Publication provides guidance to the selection and configuration of TLS protocol implementations while making effective use of Federal Information Processing Standards (FIPS) and NIST-recommended cryptographic algorithms. It requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and requires support for TLS 1.3 by January 1, 2024. This Special Publication also provides guidance on certificates and TLS extensions that impact security.

show abstract

“…Although a number of key management techniques have been submitted to the scrutiny of experts and follow industry standards such as ISO [22], ANSI [23], and NIST [24]- [26], many key management applications that contain their own unique proprietary protocols with the aim of avoiding issues relating to incompatibility have been proposed.…”

Section: Architecture Of Secure Key Managementmentioning

confidence: 99%

Efficient Key Management Protocol for Secure RTMP Video Streaming toward Trusted Quantum Network

Pattaranantakul¹,

Sanguannam²,

Sangwongngam³

et al. 2015

ETRI J

View full text Add to dashboard Cite

This paper presents an achievable secure videoconferencing system based on quantum key encryption in which key management can be directly applied and embedded in a server/client videoconferencing model using, for example, OpenMeeting. A secure key management methodology is proposed to ensure both a trusted quantum network and a secure videoconferencing system. The proposed methodology presents architecture on how to share secret keys between key management servers and distant parties in a secure domain without transmitting any secrets over insecure channels. The advantages of the proposed secure key management methodology overcome the limitations of quantum point‐to‐point key sharing by simultaneously distributing keys to multiple users; thus, it makes quantum cryptography a more practical and secure solution. The time required for the encryption and decryption may cause a few seconds delay in video transmission, but this proposed method protects against adversary attacks.

show abstract

Recommendation for Key Management Part 3: Application-Specific Key Management Guidance

Cited by 41 publications

References 0 publications

Making the Case for Elliptic Curves in DNSSEC

Making the Case for Elliptic Curves in DNSSEC

Guidelines for the selection, configuration, and use of Transport Layer Security (TLS) implementations

Efficient Key Management Protocol for Secure RTMP Video Streaming toward Trusted Quantum Network

Contact Info

Product

Resources

About