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 expand data unpredictably, lack compatibility with network tools, and are not designed for high-volume processing. The specialized methods in this specification address these requirements:¶

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

• 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: All conforming implementations produce identical results, enabling data exchange between different systems, vendors, and programming languages.¶

These specialized encryption methods enable several use cases:¶

• Privacy Protection: Prevents exposure of sensitive user information to third parties in logs, analytics data, and network measurements ([RFC6973]). The key holder retains decryption capability.¶

• Correlation Attack Resistance: 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 counting unique clients, rate limiting, or deduplication without revealing original values. This addresses the anonymization requirements for DNS query data sharing outlined in [RSSAC040]. The ipcrypt-pfx variant preserves network prefixes for network-level analytics, while other methods scramble network hierarchy.¶

• Third-Party Integration: Encrypted IP addresses can serve as privacy-preserving identifiers when interacting with untrusted services, cloud providers, or external platforms.¶

The following examples demonstrate how the same IP addresses transform under each method:¶

• Format-preserving: Valid IP addresses, same input always produces same output:¶

192.168.1.1   -> d1e9:518:d5bc:4487:51c6:c51f:44ed:e9f6
192.168.1.254 -> fd7e:f70f:44d7:cdb2:2992:95a1:e692:7696
192.168.1.254 -> fd7e:f70f:44d7:cdb2:2992:95a1:e692:7696  # Same output

• Prefix-preserving: Maintains network structure, same prefix when IPs share prefix:¶

192.168.1.1   -> 251.81.131.124
192.168.1.254 -> 251.81.131.159       # Prefix is preserved
172.16.69.42  -> 165.228.146.177

• Non-deterministic: Larger output, different each time:¶

192.168.1.1   -> f0ea0bbd...03aa9fcb
192.168.1.254 -> 620b58d8...2ff8086f
192.168.1.254 -> 35fc2338...25abed5d  # Same input, different outputs

These methods achieve optimal efficiency for their security goals: each variant uses the minimum ciphertext expansion and fewest cryptographic operations needed for its properties (format preservation, prefix preservation, or correlation resistance).¶

For implementation guidelines, 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 AES-based cryptographic primitives used 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

Conversion algorithm:¶

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 16 bytes (128 bits). As AES-128 is a permutation, each distinct input maps to a unique ciphertext, producing a valid IP address representation.¶

Test vectors are provided in Appendix A.1.¶

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

5.2. Format Preservation and Limitations

6.1. Prefix-Preserving Construction

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

Encryption process for non-deterministic modes:¶

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

Decryption process:¶

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. 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 apply per cryptographic key; rotating keys extends secure usage beyond these bounds.¶

7.3. Output Format and Encoding

The output of non-deterministic encryption is binary data. For text representation, the binary output MUST be encoded (e.g., hexadecimal or Base64). Implementations SHOULD document their chosen encoding method.¶

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. Repeated inputs result in identical ciphertexts, revealing repetition.¶

This makes deterministic encryption suitable for applications where format preservation is required and linkability is acceptable.¶

8.2. Non-Deterministic Mode Security

The inclusion of a random tweak ensures that encrypting the same input generally produces different outputs. An (input, tweak) collision reveals only that the same input was processed with that tweak, not the input’s value.¶

Security is determined by the underlying block cipher (≈2¹²⁸ 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

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

See Section 9.1.1 for a diagram of this process.¶

function ipv4_to_16_bytes(ipv4_address):
    // Parse the IPv4 address into 4 octets
    octets = parseIPv4(ipv4_address)  // Returns 4 octets
    // 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 octet in octets:
         bytes16.append(octet)
    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 {0x20, 0x01, 0x0d, 0xb8, ..., 0x34}.¶

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

This function converts a 16-byte array back to an IP address string. For IPv6 addresses, the output conforms to [RFC5952]. Implementers SHOULD use existing IP address formatting functions from standard libraries.¶

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 with canonical representation
         words = []
         for i from 0 to 8:
             word = (bytes16[i*2] << 8) | bytes16[i*2+1]
             words.append(word)

         // Find longest run of consecutive zeros for compression
         best_run_start = -1
         best_run_length = 0
         run_start = -1

         for i from 0 to 8:
             if words[i] == 0:
                 if run_start == -1:
                     run_start = i
             else:
                 if run_start != -1:
                     run_length = i - run_start
                     if run_length > best_run_length:
                         best_run_start = run_start
                         best_run_length = run_length
                     run_start = -1

         // Check final run
         if run_start != -1:
             run_length = 8 - run_start
             if run_length > best_run_length:
                 best_run_start = run_start
                 best_run_length = run_length

         // Build IPv6 string with zero compression
         parts = []
         i = 0
         while i < 8:
             if best_run_length >= 2 and i == best_run_start:
                 // Insert :: for compressed zeros
                 parts.append("" if i == 0 else ":")
                 parts.append("")
                 i += best_run_length
             else:
                 parts.append(format_hex(words[i]))
                 i += 1

         return join(parts, ":")

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 already 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_mapped(bytes16):
        prefix_start = 96
        // Set up the IPv4-mapped IPv6 prefix
        encrypted[10] = 0xFF
        encrypted[11] = 0xFF
    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, original_bit)

    // Convert back to IP format
    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_mapped(encrypted_bytes):
        prefix_start = 96
        // Set up the IPv4-mapped IPv6 prefix
        decrypted[10] = 0xFF
        decrypted[11] = 0xFF
    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)
        original_bit = cipher_bit ^ encrypted_bit
        set_bit(decrypted, bit_pos, original_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, original_bit)

    // Convert back to IP format
    return bytes_16_to_ip(decrypted)

function is_ipv4_mapped(bytes16):
    // Returns true if the 16-byte array has the IPv4-mapped IPv6 prefix (::ffff:0:0/96)
    ipv4_mapped_prefix = [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF]
    return bytes16[0..12] == ipv4_mapped_prefix

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 guide for implementing the KIASU-BC tweakable block cipher used in ipcrypt-nd.¶

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, 4):
        padded[i*4]   = tweak[i*2]
        padded[i*4+1] = tweak[i*2+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

[FIPS-197]

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

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

[RFC5952]

Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/rfc/rfc5952>.

[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]

Black, J. and P. Rogaway, "Format-Preserving Encryption", CT-RSA 2002, LNCS 2271, pp. 114–130 , 8 February 2002, <https://www.cs.ucdavis.edu/~rogaway/papers/subset.pdf>.

[DEOXYS-TBC]

Jean, J., Nikolić, I., Peyrin, T., and Y. Seurin, "The Deoxys AEAD Family", Journal of Cryptology 34, 31 (2021) , 10 June 2021, <https://thomaspeyrin.github.io/web/assets/docs/papers/Jean-etal-JoC2021.pdf>.

[FAST]

Betul Durak, F., Horst, H., and S. Vaudenay, "FAST: Format-Preserving Encryption via Shortened AES Tweakable Block Cipher", Cryptology ePrint Archive Paper 2021/1171, 14 September 2021, <https://eprint.iacr.org/2021/1171.pdf>.

[IEEE-P1619]

IEEE, "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices", IEEE 1619-2007, 4 March 2008, <https://ieeexplore.ieee.org/document/4493450>.

[KIASU-BC]

Jean, J., Nikolić, I., and T. Peyrin, "Tweaks and Keys for Block Ciphers: the TWEAKEY Framework", ASIACRYPT 2014, LNCS 8874, pp. 274–288 , December 2014, <https://eprint.iacr.org/2014/831.pdf>.

[LRW2002]

Liskov, M., Rivest, R., and D. Wagner, "Tweakable Block Ciphers", CRYPTO 2002, LNCS 2442, pp. 31–46 , 18 August 2002, <https://people.csail.mit.edu/rivest/pubs/LRW02.pdf>.

[REVISITING-SUM]

Gunsing, A., Bhaumik, R., Jha, A., Mennink, B., and Y. Shen, "Revisiting the Indifferentiability of the Sum of Permutations", CRYPTO 2023, LNCS 14083, pp. 628–660 , 9 August 2023, <https://eprint.iacr.org/2023/840.pdf>.

[RSSAC040]

ICANN RSSAC, "RSSAC040: Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis", ICANN RSSAC RSSAC040, 7 August 2018, <https://www.icann.org/en/system/files/files/rssac-040-07aug18-en.pdf>.

[SKINNY]

Beierle, C., Jean, J., Koelbl, S., Leander, G., Moradi, A., Peyrin, T., Sasaki, Y., Sasdrich, P., and S. Meng Sim, "The SKINNY Family of Block Ciphers and its Low-Latency Variant MANTIS", CRYPTO 2016, LNCS 9815, pp. 123–153 , 14 August 2016, <https://eprint.iacr.org/2016/660.pdf>.

[SUM-OF-PRPS]

Lucks, S., "The Sum of PRPs Is a Secure PRF", EUROCRYPT 2000, LNCS 1807, pp. 470–484 , 14 May 2000, <https://link.springer.com/content/pdf/10.1007/3-540-45539-6_34.pdf>.

[XTS-AES]

"The XTS-AES Mode for Disk Encryption", IEEE 1619-2007, 4 March 2008, <https://ieeexplore.ieee.org/document/4493450>.

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 prefix-preserving property of ipcrypt-pfx. Addresses from the same network produce encrypted addresses that share a common encrypted prefix.¶

# 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:0:e7d1:4b9f:2c8a:f673
Encrypted IP: 7cec:702c:3503:bef:e616:96bd:be33:a9b9

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

Key:          2b7e151628aed2a6abf7158809cf4f3ca9f5ba40db214c3798f2e1c23456789a
Input IP:     2001:db8:d8b4:0: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, the tweak values shown are examples. Tweaks MUST be uniformly random for each encryption operation.¶