4kimov
commented
9 months ago Hi @fhossfel,
First of all, thank you for working on porting T-SQL, that's cool.
The short answer to why it's not presented as "secure" is because I'm not a cryptographer, and I've personally always viewed it as a converter (similar to dec-to-hex, but with bigger alphabet + a few extra features). At least that was the original intent. In my understanding, what's needed to decode ids back to numbers is to either a) know the alphabet or b) brute-force it.
But in order to lean on the side of safety, it's presented as an encoder. I'm open to exploring / understanding this further.
P.S: A bit more opinions / comments on safety here: https://news.ycombinator.com/item?id=38414914
I am in the process of implementing a T-SQL port of the algorithm so I have some understanding of the algorithm. I am a bit surprised that the algorithm is considered insecure. It is a semetric encryption algorithm and the keyspace is the factorial of the length of the alphabet. This is definitely sufficiently large.
Of course, it is very much vulnerable to plain text attacks - especially if small consecutive numbers are encoded, like the ids in a master table. The minimum length feature will not mitigate this.
But if the encoded numbers are sufficiently large and the plaintext is not known to the attacker... I don't see any issue. Could you explain why you consider the algorithm insecure?
(I admit the above ifs are pretty big in real life use cases but I was wondering about the algorithm.)