jlleitschuh
10/29/2018, 4:34 PMRandom
which is awesome!
I'm wondering why there wasn't an official Kotlin version of SecureRandom
added.
Without an official SecureRandom
100% kotlin based crypto libraries can't be implemented without adding platform specific implementations.
Dan Kaminsky did an interesting talk at defcon about why more standard libraries libraries should offer SecureRandom
by default. So many software security bugs have been caused purely because someone on the implementation side goofed and used a predictable Random number generator.
Mike
10/29/2018, 4:41 PMjlleitschuh
10/29/2018, 4:47 PMRandom
is a Pseudo Random Number Generator (PRNG). (A "linear congruential PRNG").
This means the next value can easily be calculated if you have two previous values.
https://crypto.stackexchange.com/questions/51686/how-to-determine-the-next-number-from-javas-random-method
I'm guessing that Kotlin's implementation of Random
is just using the java Random
on the JVM.
@orangy am I correct?Mike
10/29/2018, 4:48 PMorangy
10/29/2018, 4:49 PMilya.gorbunov
10/29/2018, 4:51 PMjlleitschuh
10/29/2018, 4:52 PMSecureRandom
pulls from /dev/urandom
.
Kotlin would need to do something like that for the JVM and need to come up with a way of getting a secure random value from browsers in JS.SecureRandom
number generator.
I know that if there's a goal to make Ktor
truly multi-platform, that library will need a SecureRandom
generator.ilya.gorbunov
10/29/2018, 4:54 PMSecureRandom
implementation and wrap it as Kotlin's Random class inheritor with asKotlinRandom
extension.diesieben07
10/29/2018, 4:54 PMcrypto.getRandomValues
and it seems NodeJS does, too. So that could be used for a cross-platform implementationilya.gorbunov
10/29/2018, 4:55 PMlouiscad
10/29/2018, 4:58 PMilya.gorbunov
10/29/2018, 5:00 PMjlleitschuh
10/29/2018, 5:01 PMSecureRandom
implementation to the standard library.
Dan Kaminsky covers a wide range of topics in the video above, but the first chunk covers how because stdlibs don't make SecureRandom
a priority (eg. Java where SecureRandom
extends Random
and, as such was clearly an afterthought).
The problem with having a third party library implement SecureRandom
is that that exposes an additional piece of security overhead kotlin users.
How do you know that you can trust the library you are getting your SecureRandom
implementation from? I think most people generally trust the Jetbrains team, but a SecureRandom
implementation isn't something that should just be entrusted externally lightly.orangy
10/29/2018, 5:03 PMSecureRandom
is only important if the system is exposed to some external interactions. E.g. for game level generation it’s not a problem and only exhaust entropy and slows everything down. But I’ll watch the video, thanks.jlleitschuh
10/29/2018, 5:07 PMorangy
10/29/2018, 5:10 PMEntropySource
instead of SecureRandom
? That would avoid confusion a little bit…jlleitschuh
10/29/2018, 5:36 PM/dev/urandom
and /dev/random
. Not something like /dev/uentropy
and /dev/entropy
.
You may want to consider adding default fun Random(): Random
that takes no arguments use whatever "Secure Random" implementation is added.
Then it's an opt-out of secure randomness instead an opt-in of secure randomness.DALDEI
11/03/2018, 5:24 PMjlleitschuh
03/28/2019, 5:23 PM