2^53 + 1 issue

[jd327]

See https://github.com/hashids/hashids.github.io/issues/1#issuecomment-53148326 and https://gist.github.com/alco/54beac75f1188bbe280b

Looping in @alco.

[alco]

Here's a basic proof of concept https://github.com/alco/hashids.js/commit/0b268e6873d24095a5c82548cd6d09c9e8ceb95d

The idea is to wrap input numbers in objects that provide the necessary arithmetic functions. By default the wrapper is only used internally and it simply uses native arithmetic. We also limit the range of input numbers (https://github.com/alco/hashids.js/commit/0b268e6873d24095a5c82548cd6d09c9e8ceb95d#diff-ac45510b2aa86482ae1d7551d7e6a36cR137) to ensure compatibility with implementations that use 64-bit integers or big integers.

If the user of the library passes in an object instead of a number, we don't check its range and assume it is an already wrapped number that implements all the required functions. This way, users will be able to extend the library with support for larger numbers without touching its implementation.

The only change to the public interface is in the decrypt function (https://github.com/alco/hashids.js/commit/0b268e6873d24095a5c82548cd6d09c9e8ceb95d#diff-ac45510b2aa86482ae1d7551d7e6a36cR339) were we need to pass a wrapped zero value so that we know which type to use when decoding the string back into numbers.

[jd327]

I like the idea of letting the user extend Hashids with their own library to handle big numbers a lot. I think this a) keeps Hashids small and independent of 3rd party libs for those that don't care about handling big numbers and b) the user is free to pick their own implementation.

For example I know for JavaScript, there's a few: https://github.com/jtobey/javascript-bignum https://github.com/alexbardas/bignumber.js http://jsfromhell.com/classes/bignumber

So, people might be inclined to use one over the other. Or maybe make their own.

@alco, thanks for the proof of concept. One followup question though - is there a reason it would be better to provide objects with math functions included to encode(), rather than provide a math lib to the constructor initially and provide strings of large ints to encode() after that?

[alco]

@ivanakimov It makes sense to pass the functions to encode or the Hashids constructor, it just didn't cross my mind at the time. I'll take a look at the libraries you mentioned and will try building another prototype with support for big numbers.

[zakame]

For perl, apparently it only breaks for 2^60.

I can probably use bignum here for >= 2^60.

[4kimov]

Closing since the project is moving. New algo has maxValue() method to determine upper integer limit, which will differ per implementation.