https://kotlinlang.org logo
Title
j

jlleitschuh

10/29/2018, 4:34 PM
So I notice that 1.3 adds support for an official Koltin
Random
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.

https://youtu.be/xneBjc8z0DE

m

Mike

10/29/2018, 4:41 PM
Interesting that you raise this. Does the 'random' use secured random under the covers? As there's a random that takes a seed and explicitly returns a repeatable sequence which would obviously be using Java Random. Perhaps kotlin is attempting to make it harder to use wrong Random? But I couldn't go d specific information on this.
j

jlleitschuh

10/29/2018, 4:47 PM
@Mike No, the default for java's
Random
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?
m

Mike

10/29/2018, 4:48 PM
Sorry, I was referring to the Kotlin Random. Does it use java.SecureRandom when you use kotlin.Random() and use java.Random when you use kotlin.Random({some seed value}). I wasn’t able to find specifics myself.
o

orangy

10/29/2018, 4:49 PM
@ilya.gorbunov ^^
i

ilya.gorbunov

10/29/2018, 4:51 PM
The default implementation of Random is using a pseudo-random source whichever available in the platform (e.g. ThreadLocalRandom or java.util.Random in JVM, Math.random in JS etc). The seeded implementation uses XORWOW algorithm. Neither of them are cryptographically secure.
j

jlleitschuh

10/29/2018, 4:52 PM
I'm not able to find specifics either. I'm hoping someone from the Jetbrains can weigh in. I'm guessing that by default it's not using a secure random number generator. If Kotin were to use a secure random generator, then the Kotlin platform specific libraries would need to be reaching out to the platform specific secure random utilities. For the JVM
SecureRandom
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.
@Ilya Goncharov [JB] Is there any plans to add a Kotlin stdlib way of getting a
SecureRandom
number generator. I know that if there's a goal to make
Ktor
truly multi-platform, that library will need a
SecureRandom
generator.
i

ilya.gorbunov

10/29/2018, 4:54 PM
In JVM you can use the available
SecureRandom
implementation and wrap it as Kotlin's Random class inheritor with
asKotlinRandom
extension.
👌 2
d

diesieben07

10/29/2018, 4:54 PM
Modern browsers support
crypto.getRandomValues
and it seems NodeJS does, too. So that could be used for a cross-platform implementation
i

ilya.gorbunov

10/29/2018, 4:55 PM
We do not have plans providing SecureRandom in stdlib, but we can consider implementing it as a separate library.
👍 4
l

louiscad

10/29/2018, 4:58 PM
@ilya.gorbunov Do you have any registry of Kotlin/JetBrains supported libraries considerations? I read that you plan to have something for dates, but there's also this SecureRandom thing, i18n & l10n, and more. A registry, with whether you started working on it, and which phase it is in (discussion, design, prototype, etc) would be helpful for the community that also works on libraries.
i

ilya.gorbunov

10/29/2018, 5:00 PM
No such registry, but sounds like a good idea!
❤️ 2
j

jlleitschuh

10/29/2018, 5:01 PM
I highly recommend some members of the team watch the first 20 or so min of the above linked defcon talk and consider adding a
SecureRandom
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.
o

orangy

10/29/2018, 5:03 PM
I believe
SecureRandom
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.
j

jlleitschuh

10/29/2018, 5:07 PM
Thanks. I do believe both have their place in the software world.
o

orangy

10/29/2018, 5:10 PM
May be we should call it
EntropySource
instead of
SecureRandom
? That would avoid confusion a little bit…
j

jlleitschuh

10/29/2018, 5:36 PM
@orangy You could. That being said the OS standard is to pull randomness from
/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.
@orangy Sorry, the RNG part starts 17 min in to that video. My mistake.
👍 1
d

DALDEI

11/03/2018, 5:24 PM
IMHO, If one truely wants 'cryptographic secure' Random, which is quite a different use case then various other "Random" -- and even "cryptographic secure" is a vague generic term that has little real meaning in the use cases that need it -- I would not 'trust' a language vendor's implementation, and would only trust an OS's implementation to the extent that the use case allowed for it -- i.e. the use case allows for 'Genericl, imprecisely defined "cryptographicly secure" "random" values" -- This is precisely the reason for third party well-known and well-regulated implementations such as FIPS. Start going down the 'Cryptograpically secure' route and you are fooling yourself if you believe that has any particular meaning without precise requirements and independently audited implementations that meet those specific requirements. Your program is not any more 'secure' just because you picked a "Secure" random generator -- context is everythign. Cryptographicly secure random numbers have very little to do with 'security' in general -- only when applied as precisely defined inputs in specific algorithms used itself used in very specific ways for specific use cases. Its quite easy to belive your are making your application more 'secure' by using 'Secure'-XXX functions while in reality doing nothing of the sort, or covering a very limited and specific attack vector while leaving the front door wide open.
👍 1
There are common applications (such as RSA hardware or software identity devices) which provide well defined highly secure features by using predictable RNG algorithms -- in combination with precise clocks to provide identity validation between devices which are unconnected for long periods and without exposing private keys after the initial 'burn in' at the 'factory' ('quotes' refer to software implementations of the same).
j

jlleitschuh

03/28/2019, 5:23 PM
For anyone still interested in this thread. I opened this KEEP to discuss the idea. https://github.com/Kotlin/KEEP/issues/184