Methods for IP Address Encryption and Obfuscation

1.1. 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 Section 5.2).¶

• 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 ([RFC6973]). 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 Section 7).¶

• 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 [RSSAC040], 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 Section 9.¶

1.2. 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 ([RFC6973], [RFC7258], [RFC7624]), 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.¶

3.1. Converting to a 16-Byte Representation

IPv6 Address:           2001:0db8:85a3:0000:0000:8a2e:0370:7334
16-Byte Representation: [20 01 0d b8 85 a3 00 00 00 00 8a 2e 03 70 73 34]

IPv4 Address:           192.0.2.1
16-Byte Representation: [00 00 00 00 00 00 00 00 00 00 FF FF C0 00 02 01]

3.2. 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¶

5.1. 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 Appendix A.1.¶

      +---------------------+
      |      IP Address     |
      |    (IPv4 or IPv6)   |
      +---------------------+
                 |
                 v
      +---------------------+
      | Convert to 16 Bytes |
      +---------------------+
                 |
                 v
      +---------------------+
      |   AES128 Encrypt    |
      |   (Single Block)    |
      +---------------------+
                 |
                 v
      +---------------------+
      |    16-Byte Output   |
      +---------------------+
                 |
                 v
      +---------------------+
      | Convert to IP Format|
      +---------------------+

5.2. Format Preservation and Limitations

6.1. 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).¶

6.2. 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.¶

7.1. 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.¶

7.2. 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.¶

7.3. 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.¶

7.4. 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 [KIASU-BC] for details.¶

• ipcrypt-ndx: Uses the AES-XTS tweakable block cipher with a 16-byte (128-bit) tweak. See [XTS-AES] 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 Appendix A.3 and Appendix A.4.¶

7.5. 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.¶

8.1. 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.¶

8.2. 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.¶

8.3. 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¶

8.4. 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 [RFC4086])¶

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.¶

9.1. Visual Diagrams

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

                 IPv4: 192.0.2.1
                        |
                        v
               Octets:  C0 00 02 01
                        |
                        v
                  16-Byte Array:
[00 00 00 00 00 00 00 00 00 00 | FF FF | C0 00 02 01]

            IP Address
                |
                v
       [Convert to 16 Bytes]
                |
                v
   [AES-128 Single-Block Encrypt]
                |
                v
       16-Byte Ciphertext
                |
                v
     [Convert to IP Format]
                |
                v
       Encrypted IP Address

            IP Address
                |
                v
       [Convert to 16 Bytes]
                |
                v
  [Split 32-byte key into K1, K2]
                |
                v
  [For each bit position (MSB to LSB):
  - Pad current prefix to 128 bits:
    zeros || 1 || prefix_bits
  - e1 = AES(K1, padded_prefix)
  - e2 = AES(K2, padded_prefix)
  - e = e1 ⊕ e2
  - Extract LSB from e as cipher_bit
  - XOR cipher_bit with original bit
  - Set result bit in encrypted output
  - Add original bit to prefix for next iteration]
                |
                v
       Encrypted IP Address
  (4 bytes for IPv4, 16 bytes for IPv6)

              IP Address
                  |
                  v
       [Convert to 16 Bytes]
                  |
                  v
    [Generate Random 8-Byte Tweak]
                  |
                  v
       [KIASU-BC Tweakable Encrypt]
                  |
                  v
          16-Byte Ciphertext
                  |
                  v
    [Concatenate Tweak || Ciphertext]
                  |
                  v
       24-Byte Output (ipcrypt-nd)

              IP Address
                  |
                  v
       [Convert to 16 Bytes]
                  |
                  v
    [Generate Random 16-Byte Tweak]
                  |
                  v
       [AES-XTS Tweakable Encrypt]
                  |
                  v
          16-Byte Ciphertext
                  |
                  v
    [Concatenate Tweak || Ciphertext]
                  |
                  v
       32-Byte Output (ipcrypt-ndx)

9.2. IPv4 Address Conversion

A diagram of this conversion process is provided in Section 9.1.1.¶

function ipv4_to_16_bytes(ipv4_address):
    // Split the IPv4 address into its octets
    parts = ipv4_address.split(".")
    if length(parts) != 4:
         raise Error("Invalid IPv4 address")
    // Create a 16-byte array with the IPv4-mapped prefix
    bytes16 = [0x00] * 10         // 10 bytes of 0x00
    bytes16.append(0xFF)          // 11th byte: 0xFF
    bytes16.append(0xFF)          // 12th byte: 0xFF
    // Append each octet (converted to an 8-bit integer)
    for part in parts:
         bytes16.append(int(part))
    return bytes16

Example: For "192.0.2.1", the function returns¶

[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, FF, FF, C0, 00, 02, 01]

9.3. IPv6 Address Conversion

function ipv6_to_16_bytes(ipv6_address):
    // Parse the IPv6 address into eight 16-bit words.
    words = parseIPv6(ipv6_address)  // Expands shorthand notation and returns 8 words
    bytes16 = []
    for word in words:
         high_byte = (word >> 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.¶

9.4. Conversion from a 16-Byte Array to an IP Address

function bytes_16_to_ip(bytes16):
    if length(bytes16) != 16:
         raise Error("Invalid byte array")

    // Check for the IPv4-mapped prefix
    // When an IPv4-mapped IPv6 address (::ffff:x.x.x.x) is detected,
    // it is converted back to IPv4 format. This is expected
    // behavior as IPv4 addresses are internally represented as IPv4-mapped
    // IPv6 addresses for uniform processing.
    ipv4_mapped_prefix = [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF]
    if bytes16[0..12] == ipv4_mapped_prefix:
         // Convert the 4 last bytes to an IPv4 address
         ipv4_parts = []
         for i from 12 to 16:
             ipv4_parts.append(integer_to_string(bytes16[i]))
         ipv4_address = join(ipv4_parts, ".")
         return ipv4_address
    else:
         // Convert the 16 bytes to an IPv6 address
         words = []
         for i from 0 to 16 step 2:
             word = (bytes16[i] << 8) | bytes16[i+1]
             // Format words without leading zeros for canonical IPv6 representation
             words.append(format_hex_no_leading_zeros(word))
         ipv6_address = join(words, ":")
         return ipv6_address

9.5. Deterministic Encryption (ipcrypt-deterministic)

function ipcrypt_deterministic_encrypt(ip_address, key):
    // The key MUST be exactly 16 bytes (128 bits) in length
    if length(key) != 16:
        raise Error("Key must be 16 bytes")

    bytes16 = convert_to_16_bytes(ip_address)
    ciphertext = AES128_encrypt(key, bytes16)
    encrypted_ip = bytes_16_to_ip(ciphertext)
    return encrypted_ip

function ipcrypt_deterministic_decrypt(encrypted_ip, key):
    if length(key) != 16:
        raise Error("Key must be 16 bytes")

    bytes16 = convert_to_16_bytes(encrypted_ip)
    plaintext = AES128_decrypt(key, bytes16)
    original_ip = bytes_16_to_ip(plaintext)
    return original_ip

9.6. Prefix-Preserving Encryption (ipcrypt-pfx)

function ipcrypt_pfx_encrypt(ip_address, key):
    // The key MUST be exactly 32 bytes (256 bits)
    if length(key) != 32:
        raise Error("Key must be 32 bytes")

    // Convert IP to 16-byte representation
    bytes16 = convert_to_16_bytes(ip_address)

    // Split the key into two AES-128 keys
    // IMPORTANT: K1 and K2 MUST be different
    K1 = key[0:16]
    K2 = key[16:32]

    // Initialize encrypted result with zeros
    encrypted = [0] * 16

    // If we encrypt an IPv4 address, start where the IPv4 address starts (bit 96)
    // Note the first 12 bytes of bytes16 are set to the prefix for IPv4 mapping in that case
    // This provides domain separation between an IPv4 address and the first 32 bits of an IPv6 address
    if is_ipv4(encrypted_ip):
        prefix_start = 96
    else:
        prefix_start = 0

    // Initialize padded_prefix for the starting prefix length
    padded_prefix = pad_prefix(bytes16, prefix_start)

    // Process each bit position sequentially
    // Note: prefix_len_bits represents how many bits from the MSB have been processed
    // Range is [prefix_start, 128), i.e., up to but not including 128
    for prefix_len_bits from prefix_start to 128:
        // Compute pseudorandom function with dual AES encryption
        e1 = AES128_encrypt(K1, padded_prefix)
        e2 = AES128_encrypt(K2, padded_prefix)
        e = e1 ⊕ e2
        // Output of the pseudorandom function is the least significant bit of e
        cipher_bit = get_bit(e, 0)

        // Encrypt the current bit position (processing from MSB to LSB)
        // For IPv6: prefix_len_bits=0 encrypts bit 127, prefix_len_bits=1 encrypts bit 126, etc.
        // For IPv4: prefix_len_bits=96 encrypts bit 31, prefix_len_bits=97 encrypts bit 30, etc.
        bit_pos = 127 - prefix_len_bits
        original_bit = get_bit(bytes16, bit_pos)
        set_bit(encrypted, bit_pos, cipher_bit ^ original_bit)

        // Prepare padded_prefix for next iteration
        // Shift left by 1 bit and insert the next bit from bytes16
        padded_prefix = shift_left_one_bit(padded_prefix)
        set_bit(padded_prefix, 0, get_bit(bytes16, 127 - prefix_len_bits))

    // Convert back to IP format
    // If the input was an IPv4 address, return an IPv4 address built from the last 32 bits of the encrypted block
    // If the input was an IPv6 address, return an IPv6 address built from the entire encrypted block
    if is_ipv4(ip_address):
        return bytes_4_to_ip(encrypted[12:16])
    else:
        return bytes_16_to_ip(encrypted)

function ipcrypt_pfx_decrypt(encrypted_ip, key):
    // The key MUST be exactly 32 bytes (256 bits)
    if length(key) != 32:
        raise Error("Key must be 32 bytes")

    // Convert encrypted IP to 16-byte representation
    encrypted_bytes = convert_to_16_bytes(encrypted_ip)

    // Split the key into two AES-128 keys
    K1 = key[0:16]
    K2 = key[16:32]

    // Initialize decrypted result with zeros
    decrypted = [0] * 16

    // If we decrypt an IPv4 address, start where the IPv4 address starts (bit 96)
    if is_ipv4(encrypted_ip):
        prefix_start = 96
    else:
        prefix_start = 0

    // Initialize padded_prefix for the starting prefix length
    padded_prefix = pad_prefix(decrypted, prefix_start)

    // Process each bit position sequentially
    // Note: prefix_len_bits represents how many bits from the MSB have been processed
    // Range is [prefix_start, 128), i.e., up to but not including 128
    for prefix_len_bits from prefix_start to 128:
        // Compute pseudorandom function with dual AES encryption
        e1 = AES128_encrypt(K1, padded_prefix)
        e2 = AES128_encrypt(K2, padded_prefix)
        // e is expected to be the same as during encryption since the prefix is the same
        e = e1 ⊕ e2
        // Output of the pseudorandom function is the least significant bit of e
        cipher_bit = get_bit(e, 0)

        // Decrypt the current bit position (processing from MSB to LSB)
        // For IPv6: prefix_len_bits=0 decrypts bit 127, prefix_len_bits=1 decrypts bit 126, etc.
        // For IPv4: prefix_len_bits=96 decrypts bit 31, prefix_len_bits=97 decrypts bit 30, etc.
        bit_pos = 127 - prefix_len_bits
        encrypted_bit = get_bit(encrypted_bytes, bit_pos)
        set_bit(decrypted, bit_pos, cipher_bit ^ encrypted_bit)

        // Prepare padded_prefix for next iteration
        // Shift left by 1 bit and insert the next bit from decrypted
        padded_prefix = shift_left_one_bit(padded_prefix)
        set_bit(padded_prefix, 0, get_bit(decrypted, 127 - prefix_len_bits))

    // Convert back to IP format
    // If the input was an IPv4 address, return an IPv4 address built from the last 32 bits of the decrypted block
    // If the input was an IPv6 address, return an IPv6 address built from the entire decrypted block
    if is_ipv4(encrypted_ip):
        return bytes_4_to_ip(decrypted[12:16])
    else:
        return bytes_16_to_ip(decrypted)

function is_ipv4(ip_address):
    // Check if the IP address is IPv4 based on its byte length
    // IPv4 addresses are 4 bytes, IPv6 addresses are 16 bytes
    return length(ip_address) == 4

function get_bit(data, position):
    // Extract bit at position from 16-byte array representing an IPv6 address in network byte order
    // position: 0 = LSB of byte 15, 127 = MSB of byte 0
    // Example: position 127 refers to bit 7 (MSB) of data[0]
    // Example: position 0 refers to bit 0 (LSB) of data[15]
    byte_index = 15 - (position / 8)
    bit_index = position % 8
    return (data[byte_index] >> 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

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

function ipcrypt_nd_encrypt(ip_address, key):
    if length(key) != 16:
        raise Error("Key must be 16 bytes")

    // Step 1: Generate random tweak (8 bytes)
    tweak = random_bytes(8)  // MUST be uniformly random

    // Step 2: Convert IP to 16-byte representation
    bytes16 = convert_to_16_bytes(ip_address)

    // Step 3: Encrypt using key and tweak
    ciphertext = KIASU_BC_encrypt(key, tweak, bytes16)

    // Step 4: Concatenate tweak and ciphertext
    result = concatenate(tweak, ciphertext)  // 8 bytes || 16 bytes = 24 bytes total
    return result

function ipcrypt_nd_decrypt(ciphertext, key):
    // Step 1: Split ciphertext into tweak and encrypted IP
    tweak = ciphertext[0:8]  // First 8 bytes
    encrypted_ip = ciphertext[8:24]  // Remaining 16 bytes

    // Step 2: Decrypt using key and tweak
    bytes16 = KIASU_BC_decrypt(key, tweak, encrypted_ip)

    // Step 3: Convert back to IP address
    ip_address = bytes_16_to_ip(bytes16)
    return ip_address

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

function ipcrypt_ndx_encrypt(ip_address, key):
    if length(key) != 32:
        raise Error("Key must be 32 bytes (two AES-128 keys)")

    // Step 1: Generate random tweak (16 bytes)
    tweak = random_bytes(16)  // MUST be uniformly random

    // Step 2: Convert IP to 16-byte representation
    bytes16 = convert_to_16_bytes(ip_address)

    // Step 3: Encrypt using key and tweak
    ciphertext = AES_XTS_encrypt(key, tweak, bytes16)

    // Step 4: Concatenate tweak and ciphertext
    result = concatenate(tweak, ciphertext)  // 16 bytes || 16 bytes = 32 bytes total
    return result

function ipcrypt_ndx_decrypt(ciphertext, key):
    // Step 1: Split ciphertext into tweak and encrypted IP
    tweak = ciphertext[0:16]  // First 16 bytes
    encrypted_ip = ciphertext[16:32]  // Remaining 16 bytes

    // Step 2: Decrypt using key and tweak
    bytes16 = AES_XTS_decrypt(key, tweak, encrypted_ip)

    // Step 3: Convert back to IP address
    ip_address = bytes_16_to_ip(bytes16)
    return ip_address

function AES_XTS_encrypt(key, tweak, block):
    // Split the key into two halves
    K1, K2 = split_key(key)

    // Encrypt the tweak with the second half of the key
    ET = AES128_encrypt(K2, tweak)

    // Encrypt the block: AES128(block ⊕ ET, K1) ⊕ ET
    return AES128_encrypt(K1, block ⊕ ET) ⊕ ET

function AES_XTS_decrypt(key, tweak, block):
    // Split the key into two halves
    K1, K2 = split_key(key)

    // Encrypt the tweak with the second half of the key
    ET = AES128_encrypt(K2, tweak)

    // Decrypt the block: AES128_decrypt(block ⊕ ET, K1) ⊕ ET
    return AES128_decrypt(K1, block ⊕ ET) ⊕ ET

9.9. 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.¶

8-byte tweak:    [T0 T1 T2 T3 T4 T5 T6 T7]
16-byte padded:  [T0 T1 00 00 T2 T3 00 00 T4 T5 00 00 T6 T7 00 00]

function pad_tweak(tweak):
    // Input: 8-byte tweak
    // Output: 16-byte padded tweak
    padded = [0] * 16
    for i in range(0, 8, 2):
        padded[i*2] = tweak[i]
        padded[i*2+1] = tweak[i+1]
    return padded

function kiasu_bc_encrypt(key, tweak, plaintext):
    // Input: 16-byte key, 8-byte tweak, 16-byte plaintext
    // Output: 16-byte ciphertext

    // Expand key and pad tweak
    round_keys = expand_key(key)
    padded_tweak = pad_tweak(tweak)

    // Initial round
    state = plaintext
    state = add_round_key(state, round_keys[0] ^ padded_tweak)

    // Main rounds
    for round in range(1, 10):
        state = sub_bytes(state)
        state = shift_rows(state)
        state = mix_columns(state)
        state = add_round_key(state, round_keys[round] ^ padded_tweak)

    // Final round
    state = sub_bytes(state)
    state = shift_rows(state)
    state = add_round_key(state, round_keys[10] ^ padded_tweak)

    return state

12.1. Normative References

[FAST]

Doh, Y., Ha, J., and J. Kim, "FAST: Format-Preserving Encryption via Shortened AES Tweakable Block Cipher", Cryptology ePrint Archive Report 2021/1171, 12 September 2021, <https://eprint.iacr.org/2021/1171>.

[FIPS-197]

NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, 26 November 2001, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf>.

[IEEE-P1619]

IEEE, "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices", IEEE 1619-2007, 18 December 2007, <https://standards.ieee.org/ieee/1619/2041/>.

[NIST-SP-800-38G]

NIST, "Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption", NIST SP 800-38G, March 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38G.pdf>.

[RFC4086]

Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/rfc/rfc4086>.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC7258]

Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/rfc/rfc7258>.

[RFC7624]

Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/rfc/rfc7624>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2. Informative References

[BRW2005]

Bellare, M., Rogaway, P., and D. Wagner, "Format-Preserving Encryption", CRYPTO 2005, 2005, <https://www.cs.ucdavis.edu/~rogaway/papers/subset.pdf>.

[DEOXYS-BC]

Jean, J., Nikolić, I., and T. Peyrin, "Deoxys-BC: A Highly Secure Tweakable Block Cipher", Cryptology ePrint Archive Paper 2014/427, 2014, <https://eprint.iacr.org/2014/427>.

[IPCRYPT2]

Denis, F., "ipcrypt2: IP address encryption/obfuscation tool", 2025, <https://github.com/jedisct1/ipcrypt2>.

[KIASU-BC]

Jean, J., Nikolić, I., and T. Peyrin, "Tweaks and Keys for Block Ciphers: the TWEAKEY Framework", Cryptology ePrint Archive Paper 2014/831, 2014, <https://eprint.iacr.org/2014/831>.

[LRW2002]

Liskov, M., Rivest, R., and D. Wagner, "Tweakable Block Ciphers", Fast Software Encryption 2002, 2002, <https://www.cs.berkeley.edu/~daw/papers/tweak-crypto02.pdf>.

[REVISITING-SUM]

Bhattacharjee, A., Dutta, A., List, E., and M. Nandi, "Revisiting the Indifferentiability of the Sum of Permutations", CRYPTO 2021, 2021, <https://eprint.iacr.org/2021/840>.

[RSSAC040]

ICANN RSSAC, "RSSAC040: Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis", 9 March 2021, <https://www.icann.org/en/system/files/files/rssac-040-09mar21-en.pdf>.

[SKINNY]

Beierle, C., Biryukov, A., Perrin, L., Udovenko, A., Velichkov, V., and Q. Wang, "The SKINNY Family of Block Ciphers and its Low-Latency Variant MANTIS", CRYPTO 2016, 2016, <https://eprint.iacr.org/2016/660>.

[SUM-OF-PRPS]

Lucks, S., "The Sum of PRPs Is a Secure PRF", EUROCRYPT 2000, 2000, <https://link.springer.com/chapter/10.1007/3-540-45539-6_34>.

[XTS-AES]

Black, J., Dawson, E., Gueron, S., and P. Rogaway, "The XTS-AES Mode for Disk Encryption", IEEE 1619-2007, 2010.

A.1. ipcrypt-deterministic Test Vectors

# Test vector 1
Key:          0123456789abcdeffedcba9876543210
Input IP:     0.0.0.0
Encrypted IP: bde9:6789:d353:824c:d7c6:f58a:6bd2:26eb

# Test vector 2
Key:          1032547698badcfeefcdab8967452301
Input IP:     255.255.255.255
Encrypted IP: aed2:92f6:ea23:58c3:48fd:8b8:74e8:45d8

# Test vector 3
Key:          2b7e151628aed2a6abf7158809cf4f3c
Input IP:     192.0.2.1
Encrypted IP: 1dbd:c1b9:fff1:7586:7d0b:67b4:e76e:4777

A.2. 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.¶

# Test vector 1 (IPv4)
Key:          0123456789abcdeffedcba98765432101032547698badcfeefcdab8967452301
Input IP:     0.0.0.0
Encrypted IP: 151.82.155.134

# Test vector 2 (IPv4)
Key:          0123456789abcdeffedcba98765432101032547698badcfeefcdab8967452301
Input IP:     255.255.255.255
Encrypted IP: 94.185.169.89

# Test vector 3 (IPv4)
Key:          0123456789abcdeffedcba98765432101032547698badcfeefcdab8967452301
Input IP:     192.0.2.1
Encrypted IP: 100.115.72.131

# Test vector 4 (IPv6)
Key:          0123456789abcdeffedcba98765432101032547698badcfeefcdab8967452301
Input IP:     2001:db8::1
Encrypted IP: c180:5dd4:2587:3524:30ab:fa65:6ab6:f88

# IPv4 addresses from same /24 network (10.0.0.0/24)
Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     10.0.0.47
Encrypted IP: 19.214.210.244

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     10.0.0.129
Encrypted IP: 19.214.210.80

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     10.0.0.234
Encrypted IP: 19.214.210.30

# IPv4 addresses from same /16 but different /24 networks
Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     172.16.5.193
Encrypted IP: 210.78.229.136

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     172.16.97.42
Encrypted IP: 210.78.179.241

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     172.16.248.177
Encrypted IP: 210.78.121.215

# IPv6 addresses from same /64 network (2001:db8::/64)
Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8::a5c9:4e2f:bb91:5a7d
Encrypted IP: 7cec:702c:1243:f70:1956:125:b9bd:1aba

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8::7234:d8f1:3c6e:9a52
Encrypted IP: 7cec:702c:1243:f70:a3ef:c8e:95c1:cd0d

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8::f1e0:937b:26d4:8c1a
Encrypted IP: 7cec:702c:1243:f70:443c:c8e:6a62:b64d

# IPv6 addresses from same /32 but different /48 networks
Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8:3a5c::e7d1:4b9f:2c8a:f673
Encrypted IP: 7cec:702c:3503:bef:e616:96bd:be33:a9b9

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8:9f27::b4e2:7a3d:5f91:c8e6
Encrypted IP: 7cec:702c:a504:b74e:194a:3d90:b047:2d1a

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8:d8b4::193c:a5e7:8b2f:46d1
Encrypted IP: 7cec:702c:f840:aa67:1b8:e84f:ac9d:77fb

A.3. ipcrypt-nd Test Vectors

# Test vector 1
Key:          0123456789abcdeffedcba9876543210
Input IP:     0.0.0.0
Tweak:        08e0c289bff23b7c
Output:       08e0c289bff23b7cb349aadfe3bcef56221c384c7c217b16

# Test vector 2
Key:          1032547698badcfeefcdab8967452301
Input IP:     192.0.2.1
Tweak:        21bd1834bc088cd2
Output:       21bd1834bc088cd2e5e1fe55f95876e639faae2594a0caad

# Test vector 3
Key:          2b7e151628aed2a6abf7158809cf4f3c
Input IP:     2001:db8::1
Tweak:        b4ecbe30b70898d7
Output:       b4ecbe30b70898d7553ac8974d1b4250eafc4b0aa1f80c96

A.4. ipcrypt-ndx Test Vectors

# Test vector 1
Key:          0123456789abcdeffedcba98765432101032547698badcfeefcdab8967452301
Input IP:     0.0.0.0
Tweak:        21bd1834bc088cd2b4ecbe30b70898d7
Output:       21bd1834bc088cd2b4ecbe30b70898d782db0d4125fdace61db35b8339f20ee5

# Test vector 2
Key:          1032547698badcfeefcdab89674523010123456789abcdeffedcba9876543210
Input IP:     192.0.2.1
Tweak:        08e0c289bff23b7cb4ecbe30b70898d7
Output:       08e0c289bff23b7cb4ecbe30b70898d7766a533392a69edf1ad0d3ce362ba98a

# Test vector 3
Key:          2b7e151628aed2a6abf7158809cf4f3c3c4fcf098815f7aba6d2ae2816157e2b
Input IP:     2001:db8::1
Tweak:        21bd1834bc088cd2b4ecbe30b70898d7
Output:       21bd1834bc088cd2b4ecbe30b70898d76089c7e05ae30c2d10ca149870a263e4

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