]> Fastly Inc.

fde@00f.net

Internet-Draft IP addresses are personally identifiable information that requires protection, yet common techniques such as truncation destroy data irreversibly while providing inconsistent privacy guarantees, and ad-hoc encryption schemes often lack interoperability and security analysis. This document specifies secure, efficient methods for encrypting IP addresses for privacy-preserving storage, logging, and analytics. The methods enable data analysis while protecting user privacy from third parties without key access, addressing data minimization concerns raised in . Four concrete instantiations are defined: ipcrypt-deterministic provides deterministic, format-preserving encryption with 16-byte outputs; ipcrypt-pfx provides deterministic, prefix-preserving encryption that maintains network relationships with native address sizes (4 bytes for IPv4, 16 bytes for IPv6); while ipcrypt-nd and ipcrypt-ndx introduce randomness to prevent correlation. All methods are reversible with the encryption key and designed for high-performance processing at network speeds. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction IP addresses are personally identifiable information requiring protection, yet common anonymization approaches have fundamental limitations. Truncation (zeroing parts of addresses) irreversibly destroys data while providing variable privacy levels; A /24 mask may obscure one user or thousands depending on network allocation. Hashing produces non-reversible outputs that are unsuitable for operational tasks such as abuse investigation. Ad-hoc encryption schemes often lack rigorous security analysis and have limited interoperability between systems. This document addresses these deficiencies by specifying secure, efficient, and interoperable methods for IP address encryption and obfuscation. The objective is to enable network operators, researchers, and privacy advocates to share or analyze data while protecting sensitive address information through cryptographically sound techniques. This specification addresses concerns raised in regarding confidentiality when sharing data with third parties. Unlike existing practices that obscure addresses, these methods provide mathematically provable security properties, which are discussed throughout this document and summarized in .

Use Cases and Motivations Organizations handling IP addresses require mechanisms to protect user privacy while maintaining operational capabilities. Generic encryption systems present challenges for IP addresses: such systems expand data unpredictably, lack compatibility with network tools, and operate at reduced speeds for high-volume processing. The specialized methods in this specification address these requirements through cryptographic techniques designed for IP addresses:

• Efficiency and Compactness: All variants operate on 128 bits, achieving single-block encryption speed required for network-rate processing. Non-deterministic variants add only 8-16 bytes of tweak overhead versus potentially hundreds of bytes with generic encryption. This characteristic enables processing addresses in real-time rather than requiring batch operations.
• High Usage Limits: Non-deterministic variants safely handle massive volumes - approximately 4 billion operations for ipcrypt-nd and 18 quintillion for ipcrypt-ndx per key - without degrading security. Generic encryption often requires complex key rotation schemes at lower thresholds.
• Format Preservation: The ipcrypt-deterministic and ipcrypt-pfx variants produce valid IP addresses rather than arbitrary ciphertext, enabling encrypted addresses to pass through existing network infrastructure, monitoring tools, and databases without modification. The ipcrypt-pfx variant uniquely preserves network prefix relationships while maintaining the original address type and size, enabling network-level analytics while protecting individual address identity (see ).
• Interoperability: This specification ensures that encrypted IP addresses can be exchanged between different systems, vendors, and programming languages. All conforming implementations produce identical results, enabling data exchange between systems and avoiding vendor lock-in.

These specialized encryption methods enable several use cases:

• Privacy Protection: They prevent the exposure of sensitive user information to third parties in logs, analytics data, and network measurements (). Protection is specifically against parties without key access; the key holder retains 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 revealing the original values to third-party processors. This approach addresses the anonymization requirements for DNS query data sharing outlined in , enabling research while protecting source IP privacy. The ipcrypt-pfx variant specifically preserves network prefixes for network-level analytics, while other methods completely scramble network hierarchy. Organizations requiring geographic or ASN metadata with non-prefix-preserving modes SHOULD extract and store such data separately (e.g., country, ASN) rather than utilizing IP address truncation, which provides inconsistent privacy protection and irreversibly destroys information.
• Third-Party Integration: Encrypted IP addresses can serve 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 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 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 used by ipcrypt-deterministic, ipcrypt-nd, and ipcrypt-ndx to operate a 128-bit cipher on both IPv4 and IPv6 addresses. The ipcrypt-pfx method differs by maintaining native address sizes—4 bytes for IPv4 and 16 bytes for IPv6—to preserve network structure (see ).

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. The defining characteristic is that the same IP address consistently encrypts to the same ciphertext when using the same key. Deterministic encryption is appropriate when:

• Duplicate IP addresses need to be detected in encrypted form (e.g., for rate limiting)
• Storage space is critical (produces only 16 bytes output)
• Format preservation is required (output remains a valid IP address)
• Correlation of the same address across records is acceptable

All instantiations documented in this specification (ipcrypt-deterministic, ipcrypt-pfx, ipcrypt-nd, and ipcrypt-ndx) are invertible, allowing encrypted IP addresses to be decrypted to their original values using the same key. For non-deterministic modes, the tweak must be preserved along with the ciphertext to enable decryption. Implementation details are provided in .

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. As AES-128 is a permutation, each distinct 16-byte input maps to a unique 16-byte ciphertext, preserving the IP address format. Test vectors are provided in .

Format Preservation and Limitations

Network Hierarchy Preservation Most encryption methods in this specification scramble network hierarchy, with the notable exception of ipcrypt-pfx:

• ipcrypt-deterministic, ipcrypt-nd, and ipcrypt-ndx: These methods completely scramble IPv4 and IPv6 prefixes in the encrypted output. Addresses from the same subnet appear unrelated after encryption, and geographic or topological proximity cannot be inferred.
• ipcrypt-pfx: This method preserves network prefix relationships in the encrypted output. Addresses from the same subnet share a common encrypted prefix, enabling network-level analytics while protecting the actual network identity. The encrypted prefixes themselves are cryptographically transformed and unrecognizable without the key.

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 implement a Format-Preserving Encryption (FPE) mode such as the FF1 algorithm specified in or FAST .

Preserving Metadata for Analytics Organizations requiring network metadata for analytics have two options:

1. Use ipcrypt-pfx to preserve network structure within the encrypted addresses, enabling network-level analysis while keeping actual network identities encrypted.
2. For non-prefix-preserving modes (ipcrypt-deterministic, ipcrypt-nd, ipcrypt-ndx), extract and store metadata (geographic location, ASN, network classification) as separate fields before encryption.

Both approaches provide advantages over IP address truncation (e.g., storing only /24 or /48 prefixes), which provides inconsistent protection and irreversibly destroys data. Recommended approach: 1. Extract metadata (geographic location, ASN, network type) from the original IP address 2. Store this information as separate fields alongside the encrypted IP address 3. Apply appropriate privacy-preserving aggregation to the metadata itself Example storage schema: ~~~ { “encrypted_ip”: “bde9:6789:d353:824c:d7c6:f58a:6bd2:26eb”, “country”: “US”, “asn”: 15169, “network_type”: “cloud_provider” } ~~~ This approach ensures consistent privacy protection through encryption while preserving analytical capabilities.

Prefix-Preserving Encryption Prefix-preserving encryption maintains network structure in encrypted IP addresses. Addresses from the same network produce encrypted addresses that share a common prefix, enabling privacy-preserving network analytics while preventing identification of specific networks or users. Unlike standard encryption that completely scrambles addresses, prefix-preserving encryption enables network operators to:

• Detect traffic patterns from common networks without knowing which specific networks
• Perform network-level rate limiting on encrypted addresses
• Implement DDoS mitigation while preserving user privacy
• Analyze network topology without accessing raw IP addresses

This mode balances privacy with analytical capability: individual addresses remain encrypted and network identities are cryptographically transformed, but network relationships remain visible through shared encrypted prefixes.

Prefix-Preserving Encryption Algorithm The encryption process achieves prefix preservation through a bit-by-bit transformation that maintains consistency across addresses with shared prefixes. For any two IP addresses sharing the first N bits, their encrypted forms also share the first N bits. This property holds recursively for all prefix lengths. The algorithm operates as follows:

1. Process each bit position sequentially from most significant to least significant
2. For each bit position, extract the prefix (all bits processed so far) from the original IP address
3. Apply a pseudorandom function (PRF) that takes the padded prefix as input to generate a cipher bit
4. XOR the cipher bit with the original bit at the current position to produce the encrypted bit
5. The encrypted bit depends deterministically on the prefix from the original IP, ensuring identical prefixes always produce identical encrypted prefixes

This construction ensures:

• Identical prefixes always produce identical transformations for subsequent bits
• Different prefixes produce cryptographically distinct transformations
• The transformation is deterministic yet cryptographically secure
• Network relationships are preserved while actual network identities remain encrypted

The algorithm maintains native address sizes: IPv4 addresses remain 4 bytes (32 bits) and IPv6 addresses remain 16 bytes (128 bits).

Concrete Instantiation: ipcrypt-pfx The ipcrypt-pfx instantiation implements prefix-preserving encryption using a pseudorandom function based on the XOR of two independently keyed AES-128 encryptions.

Pseudorandom Function Construction The pseudorandom function requires a 32-byte key split into two independent 16-byte AES-128 keys (K1 and K2). For each bit position, the algorithm performs:

1. Padding: The prefix (all bits processed so far from the original IP address) is padded to 128 bits using the format zeros || 1 || prefix_bits, where:
   • The prefix bits are extracted from the most significant bits of the original IP address
   • A single 1 bit serves as a delimiter at position prefix_len_bits
   • The prefix bits are placed immediately after the delimiter, from high to low positions
   • For an empty prefix (processing the first bit), this produces a block with only a single 1 bit at position 0
2. Dual Encryption: The padded prefix is encrypted independently with both K1 and K2, producing two 128-bit outputs (e1 and e2).
3. XOR Combination: The final PRF output is computed as e = e1 ⊕ e2.

Bit Encryption Process For each bit position (processing from MSB to LSB):

1. Pad the prefix (bits processed so far from the original IP) to 128 bits
2. Compute the PRF output using the padded prefix: e = AES(K1, padded_prefix) ⊕ AES(K2, padded_prefix)
3. Extract the least significant bit from the PRF output as the cipher bit
4. XOR the cipher bit with the original bit at the current position to produce the encrypted bit

Complete pseudocode implementation is provided in .

Key Requirements CRITICAL: The two 16-byte halves of the 32-byte key (K1 and K2) MUST NOT be identical. Using identical values for K1 and K2 (e.g., repeating the same 16 bytes twice) causes the XOR operation to cancel out, returning the original IP address unchanged.

Security Properties The ipcrypt-pfx construction improves upon earlier designs like CRYPTO-Pan through enhanced cryptographic security:

• Sum-of-Permutations: The XOR of two independently keyed AES-128 permutations provides security beyond the birthday bound , supporting more than 2^78 distinct IP addresses per key . This construction ensures that even with billions of encrypted addresses, security remains robust.
• Prefix-Based Context Isolation: Each bit depends on the entire prefix history.

Note: Prefix-preserving encryption intentionally reveals network structure to enable analytics. Organizations requiring complete address obfuscation should use non-prefix-preserving modes.

Implementation Considerations Key implementation characteristics:

• Computational Requirements:
  • IPv4: 64 AES-128 operations per address (2 encryptions × 32 bits)
  • IPv6: 256 AES-128 operations per address (2 encryptions × 128 bits)
• Performance Optimizations:
  • Caching encrypted prefix values (e1 and e2) significantly improves performance for addresses sharing common prefixes
  • The encryption algorithm is inherently parallelizable since AES computations for different bit positions are independent
  • The padded prefix computation can be optimized by maintaining state across iterations: instead of recomputing the padded prefix from scratch for each bit position, implementations can shift the previous padded prefix left by one bit and insert the next input bit.

Non-Deterministic Encryption Non-deterministic encryption enhances privacy by ensuring that the same IP address produces different ciphertexts each time it is encrypted, preventing correlation attacks that plague deterministic schemes. This is achieved through tweakable block ciphers that incorporate random values called tweaks. Non-deterministic encryption is appropriate when:

• Preventing correlation of the same IP address across records is critical
• Storage can accommodate the additional tweak data (8-16 bytes)
• Stronger privacy guarantees than deterministic encryption provides are required
• Processing the same address multiple times without revealing repetition patterns

Implementation details are provided in .

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, enabling its use 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. Test vectors are provided in and .

ipcrypt-nd (KIASU-BC) The ipcrypt-nd instantiation uses the KIASU-BC tweakable block cipher with an 8-byte (64-bit) tweak. Implementation details are provided in . 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. Regular key rotation can extend secure usage beyond these bounds. The effective security is determined by the underlying block cipher’s strength. Test vectors are provided in .

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). Similar to 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 Mode selection depends on specific privacy requirements and operational constraints:

• Deterministic (ipcrypt-deterministic):
  • Output size: 16 bytes (most compact)
  • Privacy: Same IP always produces same ciphertext (allows correlation)
  • Use case: When duplicate identification is needed or when format preservation is critical
  • Performance: Fastest (single AES operation)
• Prefix-Preserving (ipcrypt-pfx):
  • Output size: 4 bytes for IPv4, 16 bytes for IPv6 (maintains native sizes)
  • Privacy: Preserves network prefix relationships while encrypting actual network identities
  • Use case: Network analytics, traffic pattern analysis, subnet monitoring, DDoS mitigation
  • Performance: Bit-by-bit processing (64 AES operations for IPv4, 256 for IPv6)
• Non-Deterministic ipcrypt-nd (KIASU-BC):
  • Output size: 24 bytes (16-byte ciphertext + 8-byte tweak)
  • Privacy: Same IP produces different ciphertexts (prevents most correlation)
  • Use case: General privacy protection with reasonable storage overhead
  • Collision resistance: Approximately 4 billion operations per key
• Non-Deterministic ipcrypt-ndx (AES-XTS):
  • Output size: 32 bytes (16-byte ciphertext + 16-byte tweak)
  • Privacy: Same IP produces different ciphertexts (prevents correlation)
  • Use case: Maximum privacy protection when storage permits
  • Collision resistance: Approximately 18 quintillion operations per key

Alternatives to Random Tweaks While this specification recommends uniformly random tweaks for non-deterministic encryption, alternative approaches may be considered:

• 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 presents considerations with random tweaks, random tweaks remain the recommended approach for practical deployments.

Security Considerations The methods specified in this document provide strong confidentiality guarantees but explicitly do not provide integrity protection. This distinction is significant for secure deployment: These methods provide protection against:

• Unauthorized parties learning the original IP addresses (without the key)
• Statistical analysis revealing patterns in network traffic (non-deterministic modes)
• Brute-force attacks on the address space (128-bit security level)

These methods do not provide protection against:

• Active attackers modifying, reordering, or removing encrypted addresses
• Authorized key holders decrypting addresses (by design)
• Traffic analysis based on volume and timing (metadata)

Applications requiring integrity protection must additionally employ authentication mechanisms such as HMAC, authenticated encryption modes, or digital signatures over the encrypted data. While outside this specification’s scope, implementers should evaluate whether their threat model requires such additional protections.

Deterministic Mode Security A permutation ensures distinct inputs yield distinct outputs. However, repeated inputs result in identical ciphertexts, thereby revealing repetition. This property renders deterministic encryption suitable for applications where format preservation is required and 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. In the pseudocode throughout this document, the notation “for i from x to y” indicates iteration starting at x (inclusive) and ending before y (exclusive). For example, “for i from 0 to 4” processes values 0, 1, 2, and 3, but not 4.

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

IPv4 Address Conversion Diagram

Deterministic Encryption Flow

Prefix-Preserving Encryption Flow (ipcrypt-pfx)

Non-Deterministic Encryption Flow (ipcrypt-nd)

Non-Deterministic Encryption Flow (ipcrypt-ndx)

IPv4 Address Conversion A diagram of this conversion process is provided in . 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)

Encryption

Decryption

Prefix-Preserving Encryption (ipcrypt-pfx)

Encryption

Decryption

Helper Functions The following helper functions are used in the ipcrypt-pfx implementation: > bit_index) & 1 function set_bit(data, position, value): // Set bit at position in 16-byte array representing an IPv6 address in network byte order // position: 0 = LSB of byte 15, 127 = MSB of byte 0 byte_index = 15 - (position / 8) bit_index = position % 8 data[byte_index] |= ((value & 1) << bit_index) function pad_prefix(data, prefix_len_bits): // Specialized for the only two cases used: 0 and 96 // For prefix_len_bits=0: Returns a block with only bit 0 set (position 0 = LSB of byte 15) // For prefix_len_bits=96: Returns the IPv4-mapped prefix with separator at position 96 if prefix_len_bits == 0: // For IPv6 addresses starting from bit 0 padded_prefix = [0] * 16 padded_prefix[15] = 0x01 // Set bit at position 0 (LSB of byte 15) return padded_prefix else if prefix_len_bits == 96: // For IPv4 addresses, always returns the same value since all IPv4 addresses // share the same IPv4-mapped prefix (00...00 ffff) padded_prefix = [0] * 16 padded_prefix[3] = 0x01 // Set separator bit at position 96 (bit 0 of byte 3) padded_prefix[14] = 0xFF // IPv4-mapped prefix padded_prefix[15] = 0xFF // IPv4-mapped prefix return padded_prefix else: raise Error("pad_prefix only supports prefix_len_bits of 0 or 96") function shift_left_one_bit(data): // Shift a 16-byte array one bit to the left // The most significant bit is lost, and a zero bit is shifted in from the right result = [0] * 16 carry = 0 // Process from least significant byte (byte 15) to most significant byte (byte 0) for i from 15 down to 0: // Current byte shifted left by 1, with carry from previous byte result[i] = ((data[i] << 1) | carry) & 0xFF // Extract the bit that will be carried to the next byte carry = (data[i] >> 7) & 1 return result ]]>

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

Encryption

Decryption

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

Encryption

Decryption

Helper Functions for AES-XTS

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

Details about these operations are provided in .

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, Output: 16 bytes
• ipcrypt-pfx: Key: 32 bytes (256 bits, split into two independent AES-128 keys), no external tweak (uses prefix as cryptographic context), Output: 4 bytes for IPv4, 16 bytes for IPv6
• ipcrypt-nd: Key: 16 bytes (128 bits), Tweak: 8 bytes (64 bits), Output: 24 bytes
• ipcrypt-ndx: Key: 32 bytes (256 bits, split into two AES-128 keys), Tweak: 16 bytes (128 bits), Output: 32 bytes

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 draft document reviewers in judging whether the specification is suitable for publication. The listing of any individual implementation does not imply endorsement. The information presented has not been independently verified. This list is not intended as a catalog of available implementations or their features. Multiple independent, interoperable implementations of the schemes described in this document have been developed:

• Awk
• C
• D
• Dart (pub.dev package)
• Elixir (hex package)
• Go
• Java (maven package)
• JavaScript/TypeScript (npm package)
• Kotlin
• PHP (Composer package)
• Python reference
• Ruby (rubygems package)
• Rust (cargo package)
• Swift
• Zig

A comprehensive list of implementations and their test results is available 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 the ipcrypt variants. 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-pfx Test Vectors The following test vectors demonstrate the correctness and prefix-preserving property of ipcrypt-pfx. Addresses from the same network produce encrypted addresses that share a common encrypted prefix, enabling network-level analysis while keeping actual network identities cryptographically protected.

Basic Test Vectors

Prefix-Preserving Test Vectors These test vectors demonstrate the prefix-preserving property. Addresses from the same network share common encrypted prefixes at the corresponding prefix length, while the encrypted prefixes themselves are cryptographically transformed and unrecognizable without the key.

ipcrypt-nd Test Vectors

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

IANA Considerations This document does not require any IANA actions.

Acknowledgments The contributions and comments from members of the IETF and the cryptographic community have contributed to this specification. Tobias Fiebig provided a thorough review of this draft.