Skip to content

Conversation

@t-bast
Copy link
Member

@t-bast t-bast commented Apr 21, 2021

In case of catastrophic failures of the OS SecureRandom instance, we add a secondary randomness source that we mix into the random stream.

This is a somewhat weak random source and should not be used on its own, but it doesn't hurt to xor it with the output of SecureRandom.

The runtimeEntropy should be customized for iOS and Android by fetching all kind of random noise available to the application (available memory, process ID, sensor data, network statistics, etc).

Thanks @robbiehanson for the iOS code!

@t-bast t-bast force-pushed the secondary-rng branch 2 times, most recently from 776180a to b469710 Compare April 22, 2021 10:55
@t-bast t-bast marked this pull request as ready for review April 22, 2021 12:10
@t-bast t-bast requested review from robbiehanson and sstone April 22, 2021 12:10
robbiehanson
robbiehanson previously approved these changes Apr 22, 2021
robbiehanson
robbiehanson previously approved these changes Apr 22, 2021
We want to ensure the application doesn't access it directly and instead
uses our utility functions that will mix in additional randomness.
In case of catastrophic failures of the SecureRandom instance, we add a
secondary randomness source that we mix into the random stream.

This is a somewhat weak random source and should not be used on its own,
but it doesn't hurt to xor it with the output of SecureRandom.

The `runtimeEntropy` should be customized for iOS and Android.
Collect some runtime statistics for iOS.
Collect some JVM statistics.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants