[cyberax]

The problem is that AES needs a 128-bit block.

Imagine that you want to obfuscate your order numbers in the database so that customers can't infer the volume of business by checking the order number.

You can use UUIDs, but you also want to keep the numbers short so they can be dictated over the phone. You can use random IDs, but then you need to lock them in the database during the object creation otherwise you might get collisions.

Or perhaps you have a distributed system and want to allocate a bunch of IDs for each node in advance.

RC-5 with its small block size neatly solves this. You can have a strictly increasing database sequence, and then just give out each node a bunch of numbers ("from 100 to 120"), and nodes can then generate IDs based on them. And there can be no collisions with other nodes because symmetric ciphers are obviously bijective.

For these kinds of use-cases performance is not an issue.

[adrian_b]

Standard AES needs an 128-bit block.

However, the AES mixing function is made from a 32-bit mixing function that is extended to blocks whose lengths are multiples of 32-bit by composing it with a byte permutation.

The standard byte permutation extends the block size from 32-bit to 128-bit, but with the current AES instructions of CPUs you can either cancel the byte permutation to get a 32-bit block size or you can replace it with a non-standard byte permutation, to get any block size that is a multiple of 32-bit.

If you cancel the byte permutation, four 32-bit words are encrypted independently, instead of one 128-bit block. This doubles the number of instructions, but this does not necessarily reduce the throughput, as the instructions may be executed concurrently, so the throughput measured in encrypted numbers will increase by a number between 2 and 4, depending on the CPU.

[tptacek]

Right, but balanced and unbalanced Feistel networks let you turn the 16-byte AES block into an arbitrarily small PRF.

[cyberax]

Well, yes. But at this point you're just making a new cipher with AES as the round function. And I think it should be at least as safe as the round function?

I have not checked lately, but is it actually the recommendation for format-preserving encryption?

[tptacek]

I don't know about "the" recommendation, but it's how NIST standardized it (FF1 and FF3, both Feistel networks) and in the NIST rubric these aren't "new ciphers"; they're "block cipher modes".

I'll say I'm more comfortable using a straightforward FPE block cipher mode with AES than I am repurposing a weaker lightweight cipher to take advantage of its 32-bit block size.

[cyberax]

Thanks! It indeed makes sense.

I used the RC-5 cipher around 2015 to do that ID generation trick (and it's still in place in AWS as I can see), and there was no NIST standard back then. It also was not a really sensitive application, we just wanted to make IDs opaque.