rfc9374v4.txt   rfc9374.txt 
skipping to change at line 128 skipping to change at line 128
spoofable (ID-5), and identify a registry where the ID is listed spoofable (ID-5), and identify a registry where the ID is listed
(ID-2); all within a 19-character identifier (ID-1). (ID-2); all within a 19-character identifier (ID-1).
This RFC is a foundational document of DRIP, as it describes the use This RFC is a foundational document of DRIP, as it describes the use
of Hierarchical Host Identity Tags (HHITs) (Section 3) as self- of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-
asserting IPv6 addresses and thereby a trustable identifier for use asserting IPv6 addresses and thereby a trustable identifier for use
as the UAS Remote ID (see Section 3 of [DRIP-ARCH]). All other DRIP- as the UAS Remote ID (see Section 3 of [DRIP-ARCH]). All other DRIP-
related technologies will enable or use HHITs as multipurpose remote related technologies will enable or use HHITs as multipurpose remote
identifiers. HHITs add explicit hierarchy to the 128-bit HITs, identifiers. HHITs add explicit hierarchy to the 128-bit HITs,
enabling DNS HHIT queries (Host ID for authentication, e.g., enabling DNS HHIT queries (Host ID for authentication, e.g.,
[DRIP-AUTH]) and use with a Differentiated Access Control (e.g. [DRIP-AUTH]) and use with a Differentiated Access Control (e.g.,
Registration Data Access Protocol (RDAP) [RFC9224]) for 3rd-party Registration Data Access Protocol (RDAP) [RFC9224]) for 3rd-party
identification endorsement (e.g., [DRIP-AUTH]). identification endorsement (e.g., [DRIP-AUTH]).
The addition of hierarchy to HITs is an extension to [RFC7401] and The addition of hierarchy to HITs is an extension to [RFC7401] and
requires an update to [RFC7343]. As this document also adds EdDSA requires an update to [RFC7343]. As this document also adds EdDSA
(Section 3.4) for Host Identities (HIs), a number of Host Identity (Section 3.4) for Host Identities (HIs), a number of Host Identity
Protocol (HIP) parameters in [RFC7401] are updated, but these should Protocol (HIP) parameters in [RFC7401] are updated, but these should
not be needed in a DRIP implementation that does not use HIP. not be needed in a DRIP implementation that does not use HIP.
HHITs as used within the context of UAS are labeled as DRIP Entity HHITs as used within the context of UAS are labeled as DRIP Entity
Tags (DETs). Throughout this document, HHIT and DET will be used Tags (DETs). Throughout this document, HHIT and DET will be used
appropriately. HHIT will be used when covering the technology, and appropriately. HHIT will be used when covering the technology, and
DET will be used in the context of UAS RID. DET will be used in the context of UAS RID.
HHITs provide self-claims of the HHIT registry. A HHIT can only be HHITs provide self-claims of the HHIT registry. A HHIT can only be
in a single registry within a registry system (e.g. DNS). in a single registry within a registry system (e.g., DNS).
HHITs are valid, though non-routable, IPv6 addresses [RFC8200]. As HHITs are valid, though non-routable, IPv6 addresses [RFC8200]. As
such, they fit in many ways within various IETF technologies. such, they fit in many ways within various IETF technologies.
1.1. HHIT Statistical Uniqueness Different from UUID or X.509 Subject 1.1. HHIT Statistical Uniqueness Different from UUID or X.509 Subject
HHITs are statistically unique through the cryptographic hash feature HHITs are statistically unique through the cryptographic hash feature
of second-preimage resistance. The cryptographically bound addition of second-preimage resistance. The cryptographically bound addition
of the hierarchy and a HHIT registration process [DRIP-REG] provide of the hierarchy and a HHIT registration process [DRIP-REG] provide
complete, global HHIT uniqueness. If the HHITs cannot be looked up complete, global HHIT uniqueness. If the HHITs cannot be looked up
skipping to change at line 308 skipping to change at line 308
Context IDs are allocated out of the namespace introduced for Context IDs are allocated out of the namespace introduced for
Cryptographically Generated Addresses (CGA) Type Tags [RFC3972]. Cryptographically Generated Addresses (CGA) Type Tags [RFC3972].
3.1. HHIT Prefix for RID Purposes 3.1. HHIT Prefix for RID Purposes
The IPv6 HHIT prefix MUST be distinct from that used in the flat- The IPv6 HHIT prefix MUST be distinct from that used in the flat-
space HIT as allocated in [RFC7343]. Without this distinct prefix, space HIT as allocated in [RFC7343]. Without this distinct prefix,
the first 4 bits of the RAA would be interpreted as the HIT Suite ID the first 4 bits of the RAA would be interpreted as the HIT Suite ID
per HIPv2 [RFC7401]. per HIPv2 [RFC7401].
Initially, for DET use, one 28-bit prefix should be assigned out of Initially, the IPv6 prefix listed in Table 1 is assigned for DET use.
the IANA IPv6 Special Purpose Address Block ([RFC6890]). It has been registered in the "IANA IPv6 Special-Purpose Address
Registry" [RFC6890].
+==========+======+==============+ +==========+======+==============+
| HHIT Use | Bits | Value | | HHIT Use | Bits | Value |
+==========+======+==============+ +==========+======+==============+
| DET | 28 | 2001:30::/28 | | DET | 28 | 2001:30::/28 |
+----------+------+--------------+ +----------+------+--------------+
Table 1 Table 1: Initial DET IPv6 Prefix
Other prefixes may be added in the future either for DET use or other Other prefixes may be added in the future either for DET use or other
applications of HHITs. For a prefix to be added to the registry in applications of HHITs. For a prefix to be added to the registry in
Section 8.2, its usage and HID allocation process have to be publicly Section 8.2, its usage and HID allocation process have to be publicly
available. available.
3.2. HHIT Suite IDs 3.2. HHIT Suite IDs
The HHIT Suite IDs specify the HI and hash algorithms. These are a The HHIT Suite IDs specify the HI and hash algorithms. These are a
superset of the 4-bit and 8-bit HIT Suite IDs as defined in superset of the 4-bit and 8-bit HIT Suite IDs as defined in
skipping to change at line 356 skipping to change at line 357
+-----------------+-------------+ +-----------------+-------------+
| RSA,DSA/SHA-256 | 1 [RFC7401] | | RSA,DSA/SHA-256 | 1 [RFC7401] |
+-----------------+-------------+ +-----------------+-------------+
| ECDSA/SHA-384 | 2 [RFC7401] | | ECDSA/SHA-384 | 2 [RFC7401] |
+-----------------+-------------+ +-----------------+-------------+
| ECDSA_LOW/SHA-1 | 3 [RFC7401] | | ECDSA_LOW/SHA-1 | 3 [RFC7401] |
+-----------------+-------------+ +-----------------+-------------+
| EdDSA/cSHAKE128 | 5 | | EdDSA/cSHAKE128 | 5 |
+-----------------+-------------+ +-----------------+-------------+
Table 2 Table 2: Initial HHIT Suite IDs
3.2.1. HDA Custom HIT Suite IDs 3.2.1. HDA Custom HIT Suite IDs
Support for 8-bit HHIT Suite IDs allows for HDA custom HIT Suite IDs. Support for 8-bit HHIT Suite IDs allows for HDA custom HIT Suite IDs
These will be assigned values greater than 15 as follows: (see Table 3).
+===================+=======+ +===================+=======+
| HHIT Suite | Value | | HHIT Suite | Value |
+===================+=======+ +===================+=======+
| HDA Private Use 1 | 254 | | HDA Private Use 1 | 254 |
+-------------------+-------+ +-------------------+-------+
| HDA Private Use 2 | 255 | | HDA Private Use 2 | 255 |
+-------------------+-------+ +-------------------+-------+
Table 3 Table 3: HDA Custom HIT
Suite IDs
These custom HIT Suite IDs, for example, may be used for large-scale These custom HIT Suite IDs, for example, may be used for large-scale
experimentation with post-quantum computing hashes or similar domain- experimentation with post-quantum computing hashes or similar domain-
specific needs. Note that currently there is no support for domain- specific needs. Note that currently there is no support for domain-
specific HI algorithms. specific HI algorithms.
They should not be used to create a "de facto standardization". They should not be used to create a "de facto standardization".
Section 8.2 states that additional Suite IDs can be made through IETF Section 8.2 states that additional Suite IDs can be made through IETF
Review. Review.
skipping to change at line 416 skipping to change at line 418
The RAA is a 14-bit field (16,384 RAAs). Management of this space is The RAA is a 14-bit field (16,384 RAAs). Management of this space is
further described in [DRIP-REG]. An RAA MUST provide a set of further described in [DRIP-REG]. An RAA MUST provide a set of
services to allocate HDAs to organizations. It SHOULD have a public services to allocate HDAs to organizations. It SHOULD have a public
policy on what is necessary to obtain an HDA. The RAA need not policy on what is necessary to obtain an HDA. The RAA need not
maintain any HIP-related services. At minimum, it MUST maintain a maintain any HIP-related services. At minimum, it MUST maintain a
DNS zone for the HDA zone delegation for discovering HIP RVS servers DNS zone for the HDA zone delegation for discovering HIP RVS servers
[RFC8004] for the HID. Zone delegation is covered in [DRIP-REG]. [RFC8004] for the HID. Zone delegation is covered in [DRIP-REG].
As DETs under administrative control may be used in many different As DETs under administrative control may be used in many different
domains (e.g., commercial, recreation, military), RAAs should be domains (e.g., commercial, recreation, military), RAAs should be
allocated in blocks (e.g. 16-19) with consideration of the likely allocated in blocks (e.g., 16-19) with consideration of the likely
size of a particular usage. Alternatively, different prefixes can be size of a particular usage. Alternatively, different prefixes can be
used to separate different domains of use of HHITs. used to separate different domains of use of HHITs.
The RAA DNS zone within the UAS DNS tree may be a PTR for its RAA. The RAA DNS zone within the UAS DNS tree may be a PTR for its RAA.
It may be a zone in a HHIT-specific DNS zone. Assume that the RAA is It may be a zone in a HHIT-specific DNS zone. Assume that the RAA is
decimal 100. The PTR record could be constructed as follows (where decimal 100. The PTR record could be constructed as follows (where
20010030 is the DET prefix): 20010030 is the DET prefix):
100.20010030.hhit.arpa. IN PTR raa.example.com. 100.20010030.hhit.arpa. IN PTR raa.example.com.
skipping to change at line 470 skipping to change at line 472
parameters. Other than the HIP DNS RR (Resource Record) [RFC8005], parameters. Other than the HIP DNS RR (Resource Record) [RFC8005],
these should not be needed in a DRIP implementation that does not use these should not be needed in a DRIP implementation that does not use
HIP. HIP.
See Section 3.2 for use of the HIT Suite in the context of DRIP. See Section 3.2 for use of the HIT Suite in the context of DRIP.
3.4.1. HOST_ID 3.4.1. HOST_ID
The HOST_ID parameter specifies the public key algorithm, and for The HOST_ID parameter specifies the public key algorithm, and for
elliptic curves, a name. The HOST_ID parameter is defined in elliptic curves, a name. The HOST_ID parameter is defined in
Section 5.2.9 of [RFC7401]. Section 5.2.9 of [RFC7401]. Table 4 adds a new HI Algorithm.
+===================+=======+===========+ +===================+=======+===========+
| Algorithm profile | Value | Reference | | Algorithm profile | Value | Reference |
+===================+=======+===========+ +===================+=======+===========+
| EdDSA | 13 | [RFC8032] | | EdDSA | 13 | [RFC8032] |
+-------------------+-------+-----------+ +-------------------+-------+-----------+
Table 4 Table 4: New EdDSA Host ID
3.4.1.1. HIP Parameter support for EdDSA 3.4.1.1. HIP Parameter support for EdDSA
The addition of EdDSA as a HI algorithm requires a subfield in the The addition of EdDSA as a HI algorithm requires a subfield in the
HIP HOST_ID parameter (Section 5.2.9 of [RFC7401]) as was done for HIP HOST_ID parameter (Section 5.2.9 of [RFC7401]) as was done for
ECDSA when used in a HIP exchange. ECDSA when used in a HIP exchange.
For HIP hosts that implement EdDSA as the algorithm, the following For HIP hosts that implement EdDSA as the algorithm, the following
EdDSA curves are represented by the following fields: EdDSA curves are represented by the fields in Figure 2
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EdDSA Curve | NULL | | EdDSA Curve | NULL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key | | Public Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2: EdDSA Curves Fields
EdDSA Curve: Curve label EdDSA Curve: Curve label
Public Key: Represented in Octet-string format [RFC8032] Public Key: Represented in Octet-string format [RFC8032]
For hosts that implement EdDSA as a HIP algorithm, the following For hosts that implement EdDSA as a HIP algorithm, the following
EdDSA curves are defined. Recommended curves are tagged accordingly: EdDSA curves are defined. Recommended curves are tagged accordingly:
+===========+==============+===========================+ +===========+==============+===========================+
| Algorithm | Curve | Values | | Algorithm | Curve | Values |
skipping to change at line 520 skipping to change at line 522
+-----------+--------------+---------------------------+ +-----------+--------------+---------------------------+
| EdDSA | EdDSA25519 | 1 [RFC8032] (RECOMMENDED) | | EdDSA | EdDSA25519 | 1 [RFC8032] (RECOMMENDED) |
+-----------+--------------+---------------------------+ +-----------+--------------+---------------------------+
| EdDSA | EdDSA25519ph | 2 [RFC8032] | | EdDSA | EdDSA25519ph | 2 [RFC8032] |
+-----------+--------------+---------------------------+ +-----------+--------------+---------------------------+
| EdDSA | EdDSA448 | 3 [RFC8032] (RECOMMENDED) | | EdDSA | EdDSA448 | 3 [RFC8032] (RECOMMENDED) |
+-----------+--------------+---------------------------+ +-----------+--------------+---------------------------+
| EdDSA | EdDSA448ph | 4 [RFC8032] | | EdDSA | EdDSA448ph | 4 [RFC8032] |
+-----------+--------------+---------------------------+ +-----------+--------------+---------------------------+
Table 5 Table 5: EdDSA Curves
3.4.1.2. HIP DNS RR support for EdDSA 3.4.1.2. HIP DNS RR support for EdDSA
The HIP DNS RR is defined in [RFC8005]. It uses the values defined The HIP DNS RR is defined in [RFC8005]. It uses the values defined
for the 'Algorithm Type' of the IPSECKEY RR [RFC4025] for its PK for the 'Algorithm Type' of the IPSECKEY RR [RFC4025] for its PK
Algorithm field. Algorithm field.
The 'Algorithm Type' value and EdDSA HI encoding are assigned per The 'Algorithm Type' value and EdDSA HI encoding are assigned per
[RFC9373]. [RFC9373].
skipping to change at line 547 skipping to change at line 549
Section 5.2.10 of [RFC7401]. Section 5.2.10 of [RFC7401].
The following HIT Suite ID is defined: The following HIT Suite ID is defined:
+=================+=======+ +=================+=======+
| HIT Suite | Value | | HIT Suite | Value |
+=================+=======+ +=================+=======+
| EdDSA/cSHAKE128 | 5 | | EdDSA/cSHAKE128 | 5 |
+-----------------+-------+ +-----------------+-------+
Table 6 Table 6: HIT Suite ID
Table 7 provides more detail on the above HIT Suite combination. Table 7 provides more detail on the above HIT Suite combination.
The output of cSHAKE128 is variable per the needs of a specific The output of cSHAKE128 is variable per the needs of a specific
ORCHID construction. It is at most 96 bits long and is directly used ORCHID construction. It is at most 96 bits long and is directly used
in the ORCHID (without truncation). in the ORCHID (without truncation).
+=======+===========+=========+===========+====================+ +=======+===========+=========+===========+====================+
| Index | Hash | HMAC | Signature | Description | | Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | | | | function | | algorithm | |
skipping to change at line 1032 skipping to change at line 1034
[RFC6890]. Future additions to this subregistry are to be made [RFC6890]. Future additions to this subregistry are to be made
through Expert Review (Section 4.5 of [RFC8126]). Entries with through Expert Review (Section 4.5 of [RFC8126]). Entries with
network-specific prefixes may be present in the registry. network-specific prefixes may be present in the registry.
+==========+======+==============+===========+ +==========+======+==============+===========+
| HHIT Use | Bits | Value | Reference | | HHIT Use | Bits | Value | Reference |
+==========+======+==============+===========+ +==========+======+==============+===========+
| DET | 28 | 2001:30::/28 | RFC 9374 | | DET | 28 | 2001:30::/28 | RFC 9374 |
+----------+------+--------------+-----------+ +----------+------+--------------+-----------+
Table 8 Table 8: Registered DET IPv6 Prefix
Criteria that should be applied by the designated experts includes Criteria that should be applied by the designated experts includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
functionality and whether the registration description is clear and functionality and whether the registration description is clear and
fits the purpose of this registry. fits the purpose of this registry.
Registration requests MUST be sent to drip-reg-review@ietf.org and be Registration requests MUST be sent to drip-reg-review@ietf.org and be
evaluated within a three-week review period on the advice of one or evaluated within a three-week review period on the advice of one or
more designated experts. Within that review period, the designated more designated experts. Within that review period, the designated
experts will either approve or deny the registration request, and experts will either approve or deny the registration request, and
skipping to change at line 1076 skipping to change at line 1078
+-------------------+-------+-----------+ +-------------------+-------+-----------+
| ECDSA_LOW/SHA-1 | 3 | [RFC7401] | | ECDSA_LOW/SHA-1 | 3 | [RFC7401] |
+-------------------+-------+-----------+ +-------------------+-------+-----------+
| EdDSA/cSHAKE128 | 5 | RFC 9374 | | EdDSA/cSHAKE128 | 5 | RFC 9374 |
+-------------------+-------+-----------+ +-------------------+-------+-----------+
| HDA Private Use 1 | 254 | RFC 9374 | | HDA Private Use 1 | 254 | RFC 9374 |
+-------------------+-------+-----------+ +-------------------+-------+-----------+
| HDA Private Use 2 | 255 | RFC 9374 | | HDA Private Use 2 | 255 | RFC 9374 |
+-------------------+-------+-----------+ +-------------------+-------+-----------+
Table 9 Table 9: Registered HHIT Suite IDs
The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be
replicated as HIT Suite IDs (Section 8.4) as is 5 here. Higher replicated as HIT Suite IDs (Section 8.4) as is 5 here. Higher
values (32 - 255) are for those Suite IDs that need not or cannot be values (32 - 255) are for those Suite IDs that need not or cannot be
accommodated as a HIT Suite ID. accommodated as a HIT Suite ID.
8.3. IANA CGA Registry Update 8.3. IANA CGA Registry Update
This document has been added as a reference for the "CGA Extension This document has been added as a reference for the "CGA Extension
Type Tags" registry [IANA-CGA]. IANA has the following Context ID in Type Tags" registry [IANA-CGA]. IANA has the following Context ID in
skipping to change at line 1118 skipping to change at line 1120
This document defines the new EdDSA Host ID with value 13 This document defines the new EdDSA Host ID with value 13
(Section 3.4.1) in the "HI Algorithm" subregistry of the "Host (Section 3.4.1) in the "HI Algorithm" subregistry of the "Host
Identity Protocol (HIP) Parameters" registry. Identity Protocol (HIP) Parameters" registry.
+===================+=======+===========+ +===================+=======+===========+
| Algorithm Profile | Value | Reference | | Algorithm Profile | Value | Reference |
+===================+=======+===========+ +===================+=======+===========+
| EdDSA | 13 | [RFC8032] | | EdDSA | 13 | [RFC8032] |
+-------------------+-------+-----------+ +-------------------+-------+-----------+
Table 11 Table 11: Registered HI Algorithm
EdDSA Curve Label: EdDSA Curve Label:
This document specifies a new algorithm-specific subregistry named This document specifies a new algorithm-specific subregistry named
"EdDSA Curve Label". The values for this subregistry are defined "EdDSA Curve Label". The values for this subregistry are defined
in Section 3.4.1.1. Future additions to this subregistry are to in Section 3.4.1.1. Future additions to this subregistry are to
be made through IETF Review (Section 4.8 of [RFC8126]). be made through IETF Review (Section 4.8 of [RFC8126]).
+===========+==============+=========+============+ +===========+==============+=========+============+
| Algorithm | Curve | Value | Reference | | Algorithm | Curve | Value | Reference |
+===========+==============+=========+============+ +===========+==============+=========+============+
skipping to change at line 1142 skipping to change at line 1144
+-----------+--------------+---------+------------+ +-----------+--------------+---------+------------+
| EdDSA | EdDSA25519ph | 2 | [RFC8032] | | EdDSA | EdDSA25519ph | 2 | [RFC8032] |
+-----------+--------------+---------+------------+ +-----------+--------------+---------+------------+
| EdDSA | EdDSA448 | 3 | [RFC8032] | | EdDSA | EdDSA448 | 3 | [RFC8032] |
+-----------+--------------+---------+------------+ +-----------+--------------+---------+------------+
| EdDSA | EdDSA448ph | 4 | [RFC8032] | | EdDSA | EdDSA448ph | 4 | [RFC8032] |
+-----------+--------------+---------+------------+ +-----------+--------------+---------+------------+
| | | 5-65535 | Unassigned | | | | 5-65535 | Unassigned |
+-----------+--------------+---------+------------+ +-----------+--------------+---------+------------+
Table 12 Table 12: Registered EdDSA Curve Labels
HIT Suite ID: HIT Suite ID:
This document defines the new HIT Suite of EdDSA/cSHAKE with value This document defines the new HIT Suite of EdDSA/cSHAKE with value
5 (Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host 5 (Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host
Identity Protocol (HIP) Parameters" registry. Identity Protocol (HIP) Parameters" registry.
+=================+=======+===========+ +=================+=======+===========+
| Suite ID | Value | Reference | | Suite ID | Value | Reference |
+=================+=======+===========+ +=================+=======+===========+
| EdDSA/cSHAKE128 | 5 | RFC 9374 | | EdDSA/cSHAKE128 | 5 | RFC 9374 |
+-----------------+-------+-----------+ +-----------------+-------+-----------+
Table 13 Table 13: Registered HIT Suite of
EdDSA/cSHAKE
The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F
MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here. MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here.
9. Security Considerations 9. Security Considerations
The 64-bit hash in HHITs presents a real risk of second pre-image The 64-bit hash in HHITs presents a real risk of second pre-image
cryptographic hash attack (see Section 9.5). There are no known (to cryptographic hash attack (see Section 9.5). There are no known (to
the authors) studies of hash size impact on cryptographic hash the authors) studies of hash size impact on cryptographic hash
attacks. attacks.
skipping to change at line 1703 skipping to change at line 1706
+------------------+-------------------------------------+------+ +------------------+-------------------------------------+------+
| 2^72 | 1B | 10B | | 2^72 | 1B | 10B |
+------------------+-------------------------------------+------+ +------------------+-------------------------------------+------+
| 2^68 | 250M | 2.5B | | 2^68 | 250M | 2.5B |
+------------------+-------------------------------------+------+ +------------------+-------------------------------------+------+
| 2^64 | 66M | 663M | | 2^64 | 66M | 663M |
+------------------+-------------------------------------+------+ +------------------+-------------------------------------+------+
| 2^60 | 16M | 160M | | 2^60 | 16M | 160M |
+------------------+-------------------------------------+------+ +------------------+-------------------------------------+------+
Table 15 Table 15: Approximate Population Size With Collision Risk
Acknowledgments Acknowledgments
Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil
Aviation Administration. Aviation Administration.
Quynh Dang of NIST gave considerable guidance on using Keccak and the Quynh Dang of NIST gave considerable guidance on using Keccak and the
supporting NIST documents. Joan Deamen of the Keccak team was supporting NIST documents. Joan Deamen of the Keccak team was
especially helpful in many aspects of using Keccak. Nicholas especially helpful in many aspects of using Keccak. Nicholas
Gajcowski [CFRG-COMMENT] provided a concise hash pre-image security Gajcowski [CFRG-COMMENT] provided a concise hash pre-image security
 End of changes. 20 change blocks. 
22 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48.