Are there plans from JetBrains for a multiplatform...

# multiplatform

[benkuly]

Are there plans from JetBrains for a multiplatform crypto library? Iirc it was one of the most upvoted features here in slack, when someone from JetBrains asked for missing features.

[Oleg Yukhnevich]

just curios: what kind of cryptography do you want and for what specifically?
f.e.
• javax crypto also supports a lot
• js has https://nodejs.org/api/crypto.html/https://developer.mozilla.org/ru/docs/Web/API/Crypto
• native out of the box has nothing but there is openssl's librypto (or other similar library) or on darwin there is some out of the box things
• there is also a kotlin multiplatform wrapper over libsodium https://github.com/ionspin/kotlin-multiplatform-libsodium - why not to use it?
• there is also some other written in C cross platform libraries like openssl or google tink that can be wrapped
Creating a multiplatform library for cryptography is really big amount of work, and in most cases, you just need simple expect/actual over platform provided things.
P.S. I think, that you understand, that there is no sense to creating crypto library from scratch - like writing all algorithms in common kotlin 🙂

[benkuly]

Thank you for this detailed response.
• Using a third party library like kotlin-multiplatform-libsodium is no option, because I need to trust the author.
• Using expect actual is very annoying, because there are no wrappers for JS-Crypto or openssl's libcrypto. The last one also needs gradle build scripts and CI/CD to build and support all the platforms. I already did something for libolm, but it is very cumbersome.

[benkuly]

Right now I use the following JVM crypto/hash algorithms: PBKDF2WithHmacSHA512 HmacSHA256 AES/CTR/NoPadding

[benkuly]

Encoding stuff like BASE58 or BASE64 is also missing for kotlin multiplatform.

[Oleg Yukhnevich]

but it's just a libsodium wrapper, why not to trust?
so if there will be just wrappers over JS-crypto, or openssl libcrypto you also will not trust them?
Im sure, that JB will not be able to wrap ALL different crypto libraries (f.e. someone will need openssl, but other boringssl or anything else like libsodium)

[benkuly]

It's more like: I trust JetBrains more then a library, which has a big banner "Danger: Experimental" 😉

I totally understand, that JB cannot wrap ALL different crypto libraries. But I think, that it needs something like javax.crypto with a few basic algorithms. Maybe you are right and this is not realistic, but it would be one step further to a good kotlin multiplatform ecosystem.
At least supporting the most used Hashing-Algorithms and encoding (like Base64 , which could be used from ktor) would be good, because the community asked for them many times.

There are also many missing wrappers for standard Browser-APIs like indexedDB and - back to the topic - Crypto-API.

[Oleg Yukhnevich]

yeah, I saw the banner 🙂
I think, that the absence of good crypto library now is a good indicator, that it's not so easy to do it with good API and support for different algorithms (hardest thing is of course native). Comparing to f.e. logging or io libraries in ecosystem - which are also essential, and without JB there are already several exists.
regarding, hashing, I found several opensource base64 libraries and at least okio has sha* and hmac support - and I understand, that having ONE library for it will be better, but it should not be from JB in my opinion. but could be like okio, which is considered by JB as preferable choice for IO, even it's not from JB.
If you have experience with crypto/hashes, I think it's possible to create a library from community, but for this, we need to gather use cases (TBH - I don't how to do it properly)
Even I will be glad to write something like this. (I have some experience with binding openssl to linux for TLS over TCP)

[Oleg Yukhnevich]

let's try to gather use cases: https://kotlinlang.slack.com/archives/C3PQML5NU/p1651232242387729

[Zac Sweers]

Okio supports some of these and don't have a big scary warning banner

[Oleg Yukhnevich]

yes, I've already mentioned it upper

and at least okio has sha* and hmac support