Проект OpenNet: MAN pgpPktKeyV3_s (3) Библиотечные вызовы (FreeBSD и Linux)

Интерактивная система просмотра системных руководств (man-ов)

pgpPktKeyV3_s (3)

>> pgpPktKeyV3_s (3) ( Разные man: Библиотечные вызовы )

NAME

pgpPktKeyV3_s - 5.5.1.

SYNOPSIS

#include <rpmpgp.h>

Data Fields

byte version

byte time [4]

byte valid [2]

byte pubkey_algo

DETAILED DESCRIPTION

5.5.1.

Key Packet Variants

5.5.1.1. Public Key Packet (Tag 6)

A Public Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).

5.5.1.2. Public Subkey Packet (Tag 14)

A Public Subkey packet (tag 14) has exactly the same format as a Public Key packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, the top-level key provides signature services, and the subkeys provide encryption services.

Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGP ever emitted comment packets but they did properly ignore them. Public Subkey packets are ignored by PGP 2.6.x and do not cause it to fail, providing a limited degree of backward compatibility.

5.5.1.3. Secret Key Packet (Tag 5)

A Secret Key packet contains all the information that is found in a Public Key packet, including the public key material, but also includes the secret key material after all the public key fields.

5.5.1.4. Secret Subkey Packet (Tag 7)

A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key packet, and has exactly the same format.

5.5.2. Public Key Packet Formats

There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 2 packets are identical in format to Version 3 packets, but are generated by PGP 2.5 or before. V2 packets are deprecated and they MUST NOT be generated. PGP 5.0 introduced version 4 packets, with new fields and semantics. PGP 2.6.x will not accept key-material packets with versions greater than 3.

OpenPGP implementations SHOULD create keys with version 4 format. An implementation MAY generate a V3 key to ensure interoperability with old software; note, however, that V4 keys correct some security deficiencies in V3 keys. These deficiencies are described below. An implementation MUST NOT create a V3 key with a public key algorithm other than RSA.

A version 3 public key or public subkey packet contains:

A one-octet version number (3).
A four-octet number denoting the time that the key was created.
A two-octet number denoting the time in days that this key is valid. If this number is zero, then it does not expire.
A one-octet number denoting the public key algorithm of this key
A series of multi-precision integers comprising the key material:
a multiprecision integer (MPI) of RSA public modulus n;
an MPI of RSA public encryption exponent e.

V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of key IDs and fingerprints.

Definition at line 632 of file rpmpgp.h.