[AlotOfReading]

I agree with the article, but I think it could go farther. Instead of having primitives for every 32/48/64/122 bit block, we need good format-preserving encryption. Then all of this advice boils down to "use as many bits as you need" and we can keep using the standard primitives with hardware support. If you need more security in the future, you only need to decrypt and reencrypt with the new size.

[Dylan16807]

Small sizes have to be used with extra care, so I wouldn't want to make a generic function for all sizes. For bigger sizes we already have nice functions that take care of everything.

[AlotOfReading]

The article lays out exactly why you'd want small sizes, even with the risks. The good qualifier just means that it'd have to be no riskier than any other algorithm at the same length.

[Dylan16807]

I agree? That doesn't affect what I said. You shouldn't make a one-size-fits-all function that scales that small. It should have to be a deliberate choice to switch from normal mode to small mode, and anyone that hasn't looked into it deeper shouldn't even know about the small mode.

[AlotOfReading]

I suppose I don't understand your point. On one hand, you can have different algorithms for each of 32, 64, etc with potentially different pitfalls and usage requirements. On the other, you can have one algorithm that implements all of them. I wasn't trying to comment on how that should be exposed in the library (because crypto lib design is a whole 'nother topic), but I'm not opposed to it being explicit.

Same as CRCs, really. You can easily write a function that performs CRCs of any size and expose different parameterizations as CRC-8/16/32/64 etc.

[Dylan16807]

I'm responding to the idea of "use as many bits as you need" by saying it could be reasonable for small encryption but it should be kept separate from normal encryption and not made into a general statement.

Purely inside the realm of small lengths with deliberate tradeoffs I have no critique on your original statement, but I wanted to make clear that it should stay within that realm or it needs changes.

[bflesch]

Are you suggesting a very large custom blocksize? I don't think this would be feasible beyond a few megabytes.

[AlotOfReading]

No, a FPE algorithm is a cryptographic construct that uses an existing block cipher (e.g. AES-256) to construct a cryptographically secure permutation of the input without length extension. That is, input size = output size, for all sizes. Ideally, if input size >= block size of the underlying cipher, the resulting permutation is no weaker than just using the cipher directly.

You could use FPE for multi-megabyte permutations, but I don't know why you would.