[FEATURE] Hash by max time allotted #787

[sujal-ux]

Feature implementation for defining work in terms of time and not rounds is done. The required task is performed by observing the graph between number of rounds and time taken. It is observed that the relationship almost follows below formula:

number_of_rounds = log2(expected_time) + 3

The files changed are readme.md and bcrypt.js

bcrypt.hashByTime(myPlaintextPassword, expTime, function(err, hash) {
     // Store hash in your password DB.
});

genSaltByTime(...){
    .
    .
    .
    //since the relation b/w expected time and rounds roughly follows exptime = 2^(rounds-3)
    //rounds is equal to log2(expTime)+3
    rounds = Math.log(expTime)/Math.log(2);
    rounds = Math.round(rounds)+3;
    // for a secure hash, taking 4 as minimum rounds
    rounds = Math.max(rounds, 4);
    bindings.gen_salt(minor, rounds, randomBytes, cb)
}

[recrsn]

Source of this?

[sujal-ux]

While working with the code, I observed that the time taken for each round was going exponential. When I analyzed the actual time taken with the help of following snippet.

var bcrypt=require('./bcrypt.js');
async function pass(){
    for (let rounds = 1; rounds <= 20; rounds++){
        var ini = new Date();
        var hashpass = await bcrypt.hashSync("Blueisthecolorofsky", rounds);
        var fin = new Date();
        console.log(rounds,fin-ini);
    }
}
pass();

and plotted the following graph with the help of Excel,

and compared it with the graph of 2^(rounds) with different proportionality constants k:

where it was observed to be very close with constant k=1/8, leading us to believe that time taken for each round closely follows the formula:

expected_time = (1/8) * 2^(number_of_rounds)

Thus it was concluded that:

number_of_rounds = log2(expected_time) + 3

[recrsn]

As processors go faster and architectures change, the k value is going to change, the best tool is to benchmark on your server

[Symmettry]

Don't know much about this, but couldn't a max time be set then it will do more rounds until time capped--with a minimum value? or is bcrypt not built like this