]> Fastly Inc.

fde@00f.net

Internet-Draft This document specifies methods for encrypting and obfuscating IP addresses for privacy-preserving storage, logging, and analytics. These encrypted addresses enable data analysis while protecting user privacy from third parties without key access, addressing data minimization concerns raised in . Three concrete instantiations are defined: ipcrypt-deterministic provides deterministic, format-preserving encryption, while ipcrypt-nd and ipcrypt-ndx introduce randomness to prevent correlation. All methods are reversible with the encryption key. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction This document specifies methods for the encryption and obfuscation of IP addresses for both operational use and privacy preservation. The objective is to enable network operators, researchers, and privacy advocates to share or analyze data while protecting sensitive address information. This work addresses concerns raised in regarding confidentiality when sharing data with third parties. The security properties of these methods are discussed throughout this document and summarized in .

Use Cases and Motivations IP addresses are personally identifiable information (PII). While generic encryption systems can protect them, the specialized methods described here offer significant advantages with well-defined security guarantees:

• Efficiency and Compactness: All variants operate on exactly 128 bits, providing single-block encryption speed. Non-deterministic variants add only 8-16 bytes of tweak overhead compared to arbitrary expansion in generic encryption systems. This enables processing billions of addresses at network speeds.
• High Usage Limits: Non-deterministic variants support extensive operations per key - approximately 4 billion for ipcrypt-nd and 18 quintillion for ipcrypt-ndx - far exceeding typical cryptographic limits while maintaining compact outputs.
• Format Preservation (Deterministic): The ipcrypt-deterministic variant produces valid IP addresses, enabling seamless integration with existing network tools that validate IP formats (see ).
• Interoperability: By following the recommendations from this specification, implementations can reliably encrypt and decrypt IP addresses in a compatible way across different systems and vendors.

These specialized encryption methods unlock several critical use cases:

• Privacy Protection: They prevent the exposure of sensitive user information to third parties in logs, analytics data, and network measurements (). Note that protection is specifically against parties without key access; the key holder retains full decryption capability.
• Correlation Attack Resistance: While deterministic encryption can reveal repeated inputs, the non-deterministic variants leverage random tweaks to hide patterns and enhance confidentiality (see ).
• Privacy-Preserving Analytics: Encrypted IP addresses can be used directly for operations such as counting unique clients, rate limiting, or deduplication—without needing to reveal the original values to third-party processors. Note that network hierarchy and geographic relationships are not preserved.
• Seamless Third-Party Integration: Encrypted IPs can act as privacy-preserving identifiers when interacting with untrusted services, cloud providers, or external platforms.

For implementation guidelines and practical examples, see .

Relationship to IETF Work This section is to be removed before publishing as an RFC. This document does not conflict with any active IETF working group efforts. While the IETF has produced several RFCs related to privacy (, , ), there is no current standardization effort for IP address encryption methods. This specification complements existing IETF privacy guidance by providing concrete implementation methods. The cryptographic primitives used (AES, format-preserving encryption) align with IETF cryptographic recommendations, and the document follows IETF formatting and terminology conventions where applicable.

Terminology The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Throughout this document, the following terms and conventions apply:

• IP Address: An IPv4 or IPv6 address as defined in .
• 16-Byte Representation: A fixed-length representation used for both IPv4 (via IPv4-mapped IPv6) and IPv6 addresses.
• Tweak: A non-secret, additional input to a tweakable block cipher that further randomizes the output.
• Deterministic Encryption: Encryption that always produces the same ciphertext for a given input and key.
• Non-Deterministic Encryption: Encryption that produces different ciphertexts for the same input due to the inclusion of a randomly sampled tweak.
• (Input, Tweak) Collision: A scenario where the same input is encrypted with the same tweak. This reveals that the input was repeated but not the input’s value.

IP Address Conversion This section describes the conversion of IP addresses to and from a 16-byte representation. This conversion is necessary to operate a 128-bit cipher on both IPv4 and IPv6 addresses.

Converting to a 16-Byte Representation

IPv6 Addresses IPv6 addresses are natively 128 bits and are converted directly using network byte order (big-endian) as specified in . Example:

IPv4 Addresses IPv4 addresses (32 bits) are mapped using the IPv4-mapped IPv6 format as specified in :

Converting from a 16-Byte Representation to an IP Address The conversion algorithm is as follows:

1. Examine the first 12 bytes of the 16-byte representation
2. If they match the IPv4-mapped prefix (10 bytes of 0x00 followed by 0xFF, 0xFF):
   • Interpret the last 4 bytes as an IPv4 address in dotted-decimal notation
3. Otherwise:
   • Interpret the 16 bytes as an IPv6 address in colon-hexadecimal notation

Generic Constructions This specification defines two generic cryptographic constructions:

1. 128-bit Block Cipher Construction:
   • Used in deterministic encryption (see )
   • Operates on a single 16-byte block
   • Example: AES-128 treated as a permutation
2. 128-bit Tweakable Block Cipher (TBC) Construction:
   • Used in non-deterministic encryption (see )
   • Accepts a key, a tweak, and a message
   • The tweak must be uniformly random when generated
   • Reuse of the same tweak on different inputs does not compromise confidentiality

Valid options for implementing a tweakable block cipher include, but are not limited to:

• SKINNY (see )
• DEOXYS-BC (see )
• KIASU-BC (see for implementation details)
• AES-XTS (see for usage)

Implementers MUST choose a cipher that meets the required security properties and provides robust resistance against related-tweak and other cryptographic attacks.

Deterministic Encryption Deterministic encryption applies a 128-bit block cipher directly to the 16-byte representation of an IP address. All instantiations documented in this specification (ipcrypt-deterministic, ipcrypt-nd, and ipcrypt-ndx) are invertible - encrypted IP addresses can be decrypted back to their original values using the same key. For non-deterministic modes, the tweak must be preserved along with the ciphertext to enable decryption. For implementation details, see .

ipcrypt-deterministic The ipcrypt-deterministic instantiation employs AES-128 in a single-block operation. The key MUST be exactly 16 bytes (128 bits) in length. Since AES-128 is a permutation, every distinct 16-byte input maps to a unique 16-byte ciphertext, preserving the IP address format. For test vectors, see .

Format Preservation and Limitations

Network Hierarchy Preservation The encryption methods described in this specification do not preserve network hierarchy or prefix relationships.

• IPv4 and IPv6 prefixes are completely scrambled in the encrypted output
• Addresses from the same subnet will not appear related after encryption
• Geographic or topological proximity cannot be inferred from encrypted addresses

Format Preservation for IPv4 The methods specified in this document typically result in IPv4 addresses being encrypted as IPv6 addresses. IPv4 format preservation (maintaining IPv4 addresses as IPv4 rather than mapping them to IPv6) is not specified in this document and is generally discouraged due to the limited 32-bit address space, which significantly reduces encryption security. If IPv4 format preservation is absolutely required despite the security limitations, implementers SHOULD use one of the following approaches: - A 32-bit block cipher - A Format-Preserving Encryption (FPE) mode as specified in

Non-Deterministic Encryption Non-deterministic encryption leverages a tweakable block cipher together with a random tweak. For implementation details, see .

Encryption Process The encryption process for non-deterministic modes consists of the following steps:

1. Generate a random tweak using a cryptographically secure random number generator
2. Convert the IP address to its 16-byte representation
3. Encrypt the 16-byte representation using the key and the tweak
4. Concatenate the tweak with the encrypted output to form the final ciphertext

The tweak is not considered secret and is included in the ciphertext. This allows the same tweak to be used for decryption.

Decryption Process The decryption process consists of the following steps:

1. Split the ciphertext into the tweak and the encrypted IP
2. Decrypt the encrypted IP using the key and the tweak
3. Convert the resulting 16-byte representation back to an IP address

Although the tweak is generated uniformly at random, occasional collisions may occur according to birthday bounds. Such collisions are benign when they occur with different inputs. An (input, tweak) collision reveals that the same input was encrypted with the same tweak but does not disclose the input’s value. The usage limits discussed below apply per cryptographic key; rotating keys can extend secure usage beyond these bounds.

Output Format and Encoding The output of non-deterministic encryption is binary data. For applications that require text representation (e.g., logging, JSON encoding, or text-based protocols), the binary output MUST be encoded. Common encoding options include hexadecimal and Base64. The choice of encoding is application-specific and outside the scope of this specification. However, implementations SHOULD document their chosen encoding method clearly.

Concrete Instantiations This document defines two concrete instantiations:

• ipcrypt-nd: Uses the KIASU-BC tweakable block cipher with an 8-byte (64-bit) tweak. See for details.
• ipcrypt-ndx: Uses the AES-XTS tweakable block cipher with a 16-byte (128-bit) tweak. See for background.

In both cases, if a tweak is generated randomly, it MUST be uniformly random. Reusing the same randomly generated tweak on different inputs is acceptable from a confidentiality standpoint. For test vectors, see and .

ipcrypt-nd (KIASU-BC) The ipcrypt-nd instantiation uses the KIASU-BC tweakable block cipher with an 8-byte (64-bit) tweak. For implementation details, see . The output is 24 bytes total, consisting of an 8-byte tweak concatenated with a 16-byte ciphertext. Random sampling of an 8-byte tweak yields an expected collision for a specific tweak value after about 2^(64/2) = 2^32 operations (approximately 4 billion operations). If an (input, tweak) collision occurs, it indicates that the same input was processed with that tweak without revealing the input’s value. These collision bounds apply per cryptographic key. By rotating keys regularly, secure usage can be extended well beyond these bounds. The effective security is determined by the underlying block cipher’s strength. For test vectors, see .

ipcrypt-ndx (AES-XTS) The ipcrypt-ndx instantiation uses the AES-XTS tweakable block cipher with a 16-byte (128-bit) tweak. The output is 32 bytes total, consisting of a 16-byte tweak concatenated with a 16-byte ciphertext. For AES-XTS encryption of a single block, the computation avoids the sequential tweak calculations required in full XTS mode. Independent sampling of a 16-byte tweak results in an expected collision after about 2^(128/2) = 2^64 operations (approximately 18 quintillion operations). As with ipcrypt-nd, an (input, tweak) collision reveals repetition without compromising the input value. These limits are per key, and regular key rotation further extends secure usage. The effective security is governed by the strength of AES-128 (approximately 2^128 operations).

Comparison of Modes

• Deterministic (ipcrypt-deterministic): Produces a 16-byte output; preserves format but reveals repeated inputs.
• Non-Deterministic:
  • ipcrypt-nd (KIASU-BC): Produces a 24-byte output using an 8-byte tweak; (input, tweak) collisions reveal repeated inputs (with the same tweak) but not their values. Expected collision after approximately 4 billion operations per key.
  • ipcrypt-ndx (AES-XTS): Produces a 32-byte output using a 16-byte tweak; supports higher secure operation counts per key. Expected collision after approximately 18 quintillion operations per key.

Alternatives to Random Tweaks While this specification recommends the use of uniformly random tweaks for non-deterministic encryption, implementers may consider alternative approaches:

• Monotonic Counter: A counter could be used as a tweak, but this is difficult to maintain in distributed systems. If the counter is not encrypted and the tweakable block cipher is not secure against related-tweak attacks, this could enable correlation attacks.
• UUIDs: UUIDs (such as UUIDv6 or UUIDv7) could be used as tweaks; however, these would reveal the original timestamp of the logged IP addresses, which may not be desirable from a privacy perspective.

Although the birthday bound is a concern with random tweaks, the use of random tweaks remains the recommended and most practical approach, offering the best tradeoffs for most real-world use cases.

Security Considerations The ipcrypt constructions focus solely on confidentiality and do not provide integrity. This means that IP addresses in an ordered sequence can be partially removed, duplicated, reordered, or blindly altered by an active adversary. Applications that require sequences of encrypted IP addresses that cannot be modified must apply an authentication scheme over the entire sequence, such as an HMAC construction, a keyed hash function, or a public key signature. This is outside the scope of this specification, but implementers should be aware that additional authentication mechanisms are required if protection against active adversaries is needed.

Deterministic Mode Security A permutation ensures distinct inputs yield distinct outputs. However, repeated inputs result in identical ciphertexts, thereby revealing repetition. This property makes deterministic encryption suitable for applications where format preservation is required, but linkability of repeated inputs is acceptable.

Non-Deterministic Mode Security The inclusion of a random tweak ensures that encrypting the same input generally produces different outputs. In cases where an (input, tweak) collision occurs, an attacker learns only that the same input was processed with that tweak, not the value of the input itself. Security is determined by the underlying block cipher (≈2^128 for AES-128) on a per-key basis. Key rotation is recommended to extend secure usage beyond the per-key collision bounds.

Implementation Security Implementations MUST ensure that:

1. Keys are generated using a cryptographically secure random number generator
2. Tweak values are uniformly random for non-deterministic modes
3. Side-channel attacks are mitigated through constant-time operations
4. Error handling does not leak sensitive information

Key Management Considerations This specification focuses on the cryptographic transformations and does not mandate specific key management practices. However, implementers MUST ensure:

1. Keys are generated using cryptographically secure random number generators (see )
2. Keys are stored securely and access-controlled appropriately for the deployment environment
3. Key rotation policies are established based on usage volume and security requirements
4. Key compromise procedures are defined and tested

For high-volume deployments processing billions of IP addresses, regular key rotation (e.g., monthly or quarterly) is RECOMMENDED to stay well within the security bounds discussed in this document.

Implementation Details This section provides detailed pseudocode and implementation guidance for the key operations described in this document.

Visual Diagrams The following diagrams illustrate the key processes described in this specification.

IPv4 Address Conversion Diagram

Deterministic Encryption Flow

Non-Deterministic Encryption Flow (ipcrypt-nd)

Non-Deterministic Encryption Flow (ipcrypt-ndx)

IPv4 Address Conversion For a diagram of this conversion process, see . Example: For "192.0.2.1", the function returns

IPv6 Address Conversion > 8) & 0xFF low_byte = word & 0xFF bytes16.append(high_byte) bytes16.append(low_byte) return bytes16 ]]> Example: For "2001:0db8:85a3:0000:0000:8a2e:0370:7334", the output is the corresponding 16-byte sequence.

Conversion from a 16-Byte Array to an IP Address

Deterministic Encryption (ipcrypt-deterministic)

Non-Deterministic Encryption using KIASU-BC (ipcrypt-nd)

Non-Deterministic Encryption using AES-XTS (ipcrypt-ndx)

KIASU-BC Implementation Guide This section provides a detailed guide for implementing the KIASU-BC tweakable block cipher used in ipcrypt-nd. KIASU-BC is based on AES-128 with modifications to incorporate a tweak.

Overview KIASU-BC extends AES-128 by incorporating an 8-byte tweak into each round. The tweak is padded to 16 bytes and XORed with the round key at each round of the cipher. This construction is used in the ipcrypt-nd instantiation.

Tweak Padding The 8-byte tweak is padded to 16 bytes using the following method:

1. Split the 8-byte tweak into four 2-byte pairs
2. Place each 2-byte pair at the start of each 4-byte group
3. Fill the remaining 2 bytes of each group with zeros

Example:

Round Structure Each round of KIASU-BC consists of the following standard AES operations:

1. SubBytes: Apply the AES S-box to each byte of the state
2. ShiftRows: Rotate each row of the state matrix
3. MixColumns: Mix the columns of the state matrix (except in the final round)
4. AddRoundKey: XOR the state with the round key and padded tweak

For details about these operations, see .

Key Schedule The key schedule follows the standard AES-128 key expansion:

1. The initial key is expanded into 11 round keys
2. Each round key is XORed with the padded tweak before use
3. The first round key is used in the initial AddRoundKey operation

Implementation Steps

1. Key Expansion:
   • Expand the 16-byte key into 11 round keys using the standard AES key schedule
   • Each round key is 16 bytes
2. Tweak Processing:
   • Pad the 8-byte tweak to 16 bytes as described above
   • XOR the padded tweak with each round key before use
3. Encryption Process:
   • Perform initial AddRoundKey with the first tweaked round key
   • For rounds 1-9:
     • SubBytes
     • ShiftRows
     • MixColumns
     • AddRoundKey (with tweaked round key)
   • For round 10 (final round):
     • SubBytes
     • ShiftRows
     • AddRoundKey (with tweaked round key)

Example Implementation The following pseudocode illustrates the core operations of KIASU-BC: Key and tweak sizes for each variant:

• ipcrypt-deterministic: Key: 16 bytes (128 bits), no tweak
• ipcrypt-nd: Key: 16 bytes (128 bits), Tweak: 8 bytes (64 bits)
• ipcrypt-ndx: Key: 32 bytes (256 bits, two AES-128 keys), Tweak: 16 bytes (128 bits)

Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the Independent Submissions Editor in judging whether the specification is suitable for publication. Please note that the listing of any individual implementation here does not imply endorsement. Furthermore, no effort has been spent to verify the information presented here that was supplied by contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Multiple independent, interoperable implementations of the schemes described in this document have been developed:

• C implementation
• D implementation
• Go implementation
• Java implementation (maven package)
• JavaScript/TypeScript implementation (npm package)
• PHP implementation (Composer package)
• Python reference implementation
• Rust implementation (cargo package)
• Zig implementation
• Dart implementation (pub.dev package)

A comprehensive list of implementations and their test results can be found at: https://ipcrypt-std.github.io/implementations/ All implementations pass the common test vectors specified in this document, demonstrating interoperability across programming languages.

Licensing This section is to be removed before publishing as an RFC. Implementations of the ipcrypt methods are freely available under permissive open source licenses (MIT, BSD, or Apache 2.0) at the repository listed in the Implementation Status section. There are no known patent claims on these methods.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Informative References

Test Vectors This appendix provides test vectors for all three variants of ipcrypt. Each test vector includes the key, input IP address, and encrypted output. For non-deterministic variants (ipcrypt-nd and ipcrypt-ndx), the tweak value is also included. Implementations MUST verify their correctness against these test vectors before deployment.

ipcrypt-deterministic Test Vectors

ipcrypt-nd Test Vectors

ipcrypt-ndx Test Vectors For non-deterministic variants (ipcrypt-nd and ipcrypt-ndx), the tweak values shown are examples. In practice, tweaks MUST be uniformly random for each encryption operation.

IANA Considerations This document does not require any IANA actions.

Acknowledgments The author gratefully acknowledges the contributions and insightful comments from members of the IETF and the broader cryptographic community that have helped shape this specification. Special thanks to Tobias Fiebig for his thorough review of this draft.