Closed DatL4g closed 1 year ago
I thought about that too when first implementing it, but there were a few reasons it does not.
SecRandomCopyException
). Functions
for kotlin.random.Random
do not annotate this exception, so if someone were to use
org.kotlincrypto.SecureRandom
as an argument to something that accepts kotlin.random.Random
,
that's an uncaught exception for whatever that something is going to do with it.java.security.SecureRandom
. The JVM implementation of
org.kotlincrypto.SecureRandom
can only extend one or the other. I chose the latter for interoperability
purposes with JVM.IMO, any function or class that is denoting kotlin.random.Random
as an argument does not need a cryptographically secure source of random data. The default implementation kotlin.random.Random.Default
should suffice. If there is a crypto lib that is accepting kotlin.random.Random
as an argument, one should immediately stop using that library.
The SecureRandom class should extend
kotlin.random.Random
so we can use it when something wants a Kotlin Random object