This change adds a test which probes for issues with sparse inputs on the fast path.
This was driven by the issue highlighted in #163
In response to the problems raised in the above issue and those uncovered by the test 5 improvements are made to the fast path with AES. This does impose a performance peanility which appears to be about 25% in the worst case at 128 byte long inputs, but there is no overhead for short inputs (as this code path is not used) and as the overhead added is constant (not length dependent) the impact on very long inputs should be negligible.
This fixes #163 in multiple ways. Each of the improvements have been tested individually and in various combinations with weakened versions of other parts of the algorithm to insure they work as intended and provide a benifit.
This change adds a test which probes for issues with sparse inputs on the fast path. This was driven by the issue highlighted in #163
In response to the problems raised in the above issue and those uncovered by the test 5 improvements are made to the fast path with AES. This does impose a performance peanility which appears to be about 25% in the worst case at 128 byte long inputs, but there is no overhead for short inputs (as this code path is not used) and as the overhead added is constant (not length dependent) the impact on very long inputs should be negligible.
This fixes #163 in multiple ways. Each of the improvements have been tested individually and in various combinations with weakened versions of other parts of the algorithm to insure they work as intended and provide a benifit.