So I notice that 1.3 adds support for an official ...

# announcements

[jlleitschuh]

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▾

[Mike]

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.

[jlleitschuh]

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

[Mike]

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.

[orangy]

@ilya.gorbunov ^^

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

[jlleitschuh]

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.

[jlleitschuh]

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

[ilya.gorbunov]

In JVM you can use the available SecureRandom implementation and wrap it as Kotlin's Random class inheritor with asKotlinRandom extension.

[diesieben07]

Modern browsers support crypto.getRandomValues and it seems NodeJS does, too. So that could be used for a cross-platform implementation

[ilya.gorbunov]

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

[louiscad]

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

[ilya.gorbunov]

No such registry, but sounds like a good idea!

[jlleitschuh]

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.

[orangy]

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.

[jlleitschuh]

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

[orangy]

May be we should call it EntropySource instead of SecureRandom? That would avoid confusion a little bit…

[jlleitschuh]

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

[jlleitschuh]

@orangy Sorry, the RNG part starts 17 min in to that video. My mistake.

[DALDEI]

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.

[DALDEI]

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

[jlleitschuh]

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