Provide Random via injection and use SecureRandom for padding (DEV)

[d4rken]

Fixes internal sonar check.

• Replace use of Random in PaddingTool
• Provide kotlin.Random via injection to abstract away picking the right source (api level dependent)
• Provide two random sources
  • @RandomStrong for key generation
  • @RandomFast for padding (as RandomStrong can starve and block for entropy)

[mtwalli]

Lgtm

[chiljamgossow]

I don't know what this is doing, but code looks fine

[d4rken]

I don't know what this is doing, but code looks fine

The internal build pipeline raised a security warning due to our use of the default Random() which has some flaws that make it unsuitable for use with security related operations.

A suitable alternative is SecureRandom which we already inject into other classes we have.
There are different ways to instantiate SecureRandom though which offer different performance.
We already used SecureRandom.getInstanceStrong() which is nice for keys (e.g. trace locations) and anything else that will "exist" for longer durations and benefits from stronger crypthographic properties.

But getInstanceStrong and just SecureRandom() (depending on the ROM), will return an algorithm/implementation that can "starve on entropy", meaning that a call to get a new number can block/hang until enough "random stuff" has happened (time passed, user input etc.) such that SecureRandom can provide a good enough new random number.

So for the padding calculation i added a second SecureRandom with a different algorithm that is still better than Random(), worse than SecureRandom.getStrongInstance(), but can provide more random numbers, faster and without hanging.

This may be more rare on an actual device, but happens very quickly in unit-tests (especially on CIs) where the system is artificial, e.g. a VM with no good randomness source.

For testing you could run the Padding Test but inject the "Strong" instance, it has a high chance of just hanging.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

76.7% Coverage
0.0% Duplication