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?
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.
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.
Comments
Right, but balanced and unbalanced Feistel networks let you turn the 16-byte AES block into an arbitrarily small PRF.
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?
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.
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.