NIST FIPS 186-4：数字签名标准详解

信息安全

需积分: 9 94 浏览量更新于2024-07-09 收藏 774KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"NIST.FIPS.186-4.pdf Digital Signature Standard (DSS) 是美国国家标准与技术研究所（NIST）发布的一份联邦信息处理标准，用于规范数字签名算法的使用，旨在确保数据的完整性和签发者的身份验证，同时提供非否认性，防止签发者在后期否定签名行为。这份标准属于计算机安全和密码学的范畴，是信息安全领域的重要参考。" 《NIST FIPS 186-4 数字签名标准》是美国政府制定的一项标准，它详细定义了一套用于生成和验证数字签名的算法。该标准的核心目的是提供一种机制，使得数据在传输或存储过程中，即使被未经授权的修改，也能被检测出来。此外，它还能证明数据的签名是由特定实体产生的，增强了网络交易、文档签署等场景的安全性和可信度。数字签名的主要功能包括： 1. 数据完整性：通过哈希函数，数字签名可以验证数据自签名后是否发生过任何改变。一旦数据被篡改，接收方在验证签名时会发现签名不匹配，从而得知数据的完整性受到了破坏。 2. 身份认证：数字签名能确认信息发送者的身份。发送者使用私钥对数据进行签名，接收者可以用公钥验证签名，确保信息确实来自声称的发送者。 3. 非否认性：由于数字签名的不可伪造性，一旦发送者签署了数据，他们无法在后续否认这一行为。这对于法律合同、金融交易等有法律约束力的场合尤为重要。 NIST FIPS 186-4标准涵盖了多个算法，其中包括： - **RSA**：一种非对称加密算法，常用于数字签名，其中私钥用于签名，公钥用于验证。 - **DSA（Digital Signature Algorithm）**：NIST专门设计的数字签名算法，基于离散对数难题，提供安全的签名生成和验证。 - **Elliptic Curve Cryptography (ECC)**：椭圆曲线密码学，使用椭圆曲线数学，提供更高的安全性，并且需要更小的密钥长度，因此在效率和资源需求上具有优势。此外，标准还规定了如何生成和管理这些算法所需的随机数、密钥对以及证书等关键元素，以确保整个系统的安全性和可靠性。 NIST FIPS 186-4的发布和更新，旨在适应不断发展的密码技术和安全威胁，确保政府及行业的信息安全标准与技术同步进步。标准的实施和遵循对于维护公共和私人领域的网络安全至关重要，尤其在电子商务、在线银行、电子政务等领域，数字签名技术是保障交易安全的基础。

资源详情

资源推荐

1. For RSA, the modulus; the bit length of n is considered to be the

key size.

2. For ECDSA, the order of the base point of the elliptic curve; the

bit length of n is considered to be the key size.

(n, d)

An RSA private key, where n is the modulus, and d is the private

signature exponent.

(n, e)

An RSA public key, where n is the modulus, and e is the public

verification exponent.

nlen

The length of the RSA modulus n in bits.

1. For DSA, one of the DSA domain parameters; a prime number

that defines the Galois Field GF(p) and is used as a modulus in the

operations of GF(p).

2. For RSA, a prime factor of the modulus n.

1. For DSA, one of the DSA domain parameters; a prime factor of

p – 1.

2. For RSA, a prime factor of the modulus n.

An ECDSA public key.

One component of a DSA or ECDSA digital signature. See the

definition of (r, s).

(r, s)

A DSA or ECDSA digital signature, where r and s are the digital

signature components.

One component of a DSA or ECDSA digital signature. See the

definition of (r, s).

seedlen

The length of the domain_parameter_seed in bits.

SHAx(M)

The result when M is the input to the SHA-x hash function, where

SHA-x is specified in FIPS 180.

The DSA private key.

The DSA public key.

⊕

Bitwise logical “exclusive-or” on bit strings of the same length; for

corresponding bits of each bit string, the result is determined as

follows: 0 ⊕ 0 = 0, 0 ⊕ 1 = 1, 1 ⊕ 0 = 1, or 1 ⊕ 1 = 0.

Example: 01101 ⊕ 11010 = 10111

Addition.

private key must remain secret. The approved digital signature algorithms are designed to

prevent an adversary who does not know the signatory’s private key from generating the same

signature as the signatory on a different message. In other words, signatures are designed so that

they cannot be forged. A number of alternative terms are used in this Standard to refer to the

signatory or key pair owner. An entity that intends to generate digital signatures in the future

may be referred to as the intended signatory. Prior to the verification of a signed message, the

signatory is referred to as the claimed signatory until such time as adequate assurance can be

obtained of the actual identity of the signatory.

The public key is used in the signature verification process (see Figure 1). The public key need

not be kept secret, but its integrity must be maintained. Anyone can verify a correctly signed

message using the public key.

For both the signature generation and verification processes, the message (i.e., the signed data) is

converted to a fixed-length representation of the message by means of an approved hash

function. Both the original message and the digital signature are made available to a verifier.

A verifier requires assurance that the public key to be used to verify a signature belongs to the

entity that claims to have generated a digital signature (i.e., the claimed signatory). That is, a

verifier requires assurance that the signatory is the actual owner of the public/private key pair

used to generate and verify a digital signature. A binding of an owner’s identity and the owner’s

public key shall be effected in order to provide this assurance.

A verifier also requires assurance that the key pair owner actually possesses the private key

associated with the public key, and that the public key is a mathematically correct key.

By obtaining these assurances, the verifier has assurance that if the digital signature can be

correctly verified using the public key, the digital signature is valid (i.e., the key pair owner

really signed the message). Digital signature validation includes both the (mathematical)

verification of the digital signature and obtaining the appropriate assurances. The following are

reasons why such assurances are required.

1. If a verifier does not obtain assurance that a signatory is the actual owner of the key pair

whose public component is used to verify a signature, the problem of forging a signature

is reduced to the problem of falsely claiming an identity. For example, anyone in

possession of a mathematically consistent key pair can sign a message and claim that the

signatory was the President of the United States. If a verifier does not require assurance

that the President is actually the owner of the public key that is used to mathematically

verify the message’s signature, then successful signature verification provides assurance

that the message has not been altered since it was signed, but does not provide assurance

that the message came from the President (i.e., the verifier has assurance of the data’s

integrity, but source authentication is lacking).

2. If the public key used to verify a signature is not mathematically valid, the arguments

used to establish the cryptographic strength of the signature algorithm may not apply.

The owner may not be the only party who can generate signatures that can be verified

with that public key.

3. If a public key infrastructure cannot provide assurance to a verifier that the owner of a

key pair has demonstrated knowledge of a private key that corresponds to the owner’s

public key, then it may be possible for an unscrupulous entity to have their identity (or an

assumed identity) bound to a public key that is (or has been) used by another party. The

unscrupulous entity may then claim

to be the source of certain messages

signed by that other party. Or, it

may be possible that an

unscrupulous entity has managed to

obtain ownership of a public key

that was chosen with the sole

purpose of allowing for the

verification of a signature on a

specific message.

Technically, a key pair used by a digital

signature algorithm could also be used for

purposes other than digital signatures (e.g.,

for key establishment). However, a key pair

used for digital signature generation and

verification as specified in this Standard

shall not be used for any other purpose. See

SP 800-57 on Key Usage for further

information.

A number of steps are required to enable a

digital signature generation or verification

capability in accordance with this Standard.

All parties that generate digital signatures

shall perform the initial setup process as

discussed in Section 3.1. Digital signature

generation shall be performed as discussed

in Section 3.2. Digital signature verification

and validation shall be performed as

discussed in Section 3.3.

3.1 Initial Setup

Figure 2 depicts the steps that are

performed prior to generating a digital

Obtain

Assurance of Possession

of the

DS Private Key

Obtain

Assurance of Possession

of the

DS Private Key

Obtain

Assurance of

Public Key Validity

Obtain

Assurance of

Public Key Validity

Obtain

DS Key Pair

Obtain

DS Key Pair

Obtain Assurance of

Domain Parameter

Validity

Obtain Assurance of

Domain Parameter

Validity

Obtain

Domain Parameters

Obtain

Domain Parameters

Intended Signatory Ready for

Generating Digital Signatures

Intended

signatory

another

entity

generates

Intended

signatory

a TTP

generates

and Identity with a

TTP

Optional

DSA

and

ECDSA

Figure 2: Initial Setup by an Intended

Signatory

剩余129页未读，继续阅读

ruofenghan

粉丝: 0
资源: 19

NIST FIPS 186-4：数字签名标准详解

NIST.FIPS.186-4.pdf

RNG随机数标准FIPS140-2

NIST.FIPS.202

代码发送AT+CIPSTART="TCP","time.nist.gov","13"

windows时间服务器地址

没联网的Linux服务器怎么实现时间同步

国外的NTP ip地址

echo '*/5 * * * * /usr/sbin/ntpdate time.nist.gov >/dev/null 2>&1' >>/var/spool/cron/root

描述NIST评估ShA-3候选算法的一系列标准

ASPEN物性库中NIST-RK、NIST-IG、NIST-HOC的区别

rpm安装ntp的rpm包

CVE-2021-0399技术文档网站

linux更改服务器时间

温度的开源火灾检测数据集下载地址

fips 140-2 标准

linux怎么同步时间

NIST MS search2.3

linux同步时间命令

nist sp800-161下载

最新资源

echo '/5 * * * /usr/sbin/ntpdate time.nist.gov >/dev/null 2>&1' >>/var/spool/cron/root