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.

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.

@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?

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.

@ilya.gorbunov ^^

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.

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.

In JVM you can use the available

SecureRandom

implementation and wrap it as Kotlin's Random class inheritor with

asKotlinRandom

extension.

Modern browsers support

crypto.getRandomValues

and it seems NodeJS does, too. So that could be used for a cross-platform implementation

We do not have plans providing SecureRandom in stdlib, but we can consider implementing it as a separate library.

@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.

No such registry, but sounds like a good idea!

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.

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.

Thanks. I do believe both have their place in the software world.

May be we should call it

EntropySource

instead of

SecureRandom

? That would avoid confusion a little bit…

@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.

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.

For anyone still interested in this thread. I opened this KEEP to discuss the idea. https://github.com/Kotlin/KEEP/issues/184