Imagine someone (me) wants to create an opensource kotlin multiplatform crypto library with support for JVM, JS(nodejs and browser), Darwin and all other native targets
What will you need from it:1. Hashing - base64, sha*, md5, other
2. encryption: AES, DES, RSA, DH, Salsa20, other
4. key management system (like jvm key managers)
5. certificates - pem, asn.1(der), pkcs12, other
6. PBKDF2WithHmacSHA512 , HmacSHA256 and other unreadablewords
7. something else?
For what, do you need to use it and how?
s or Strings or via some lower level IO streams (like jvm InputStream/OutputStream or multiplatform ones like okio)?
What else should I know to make you happy? 🙂
1. Base64, Base58 (or a generic implementation of it), sha*
2. AES (CTR)
4. could be interesting to securely store private keys (e. g. for multiplatform Compose-Apps)
6. PBKDF2WithHmacSHA512, HmacSHA256
7. Maybe some curve algorithms (Curve25519, Ed25519) could be interesting in the future.
ByteArray would be enough for me, but IO streams like okio would be awesome.If you need help, I could support implementing some of the wrappers 😃
4 months ago
Just some context on how I see it should be implemented
I don't want to write ALL such algorithms from scratch, but use platform or library provided solutions like JVM javax.crypto, JS crypto, darwin CryptoKit (or anything else provided out of the box), openssl for linux/macos/windows and may be some others
Library should have an API to provide those implementation details without changing it public API and also have strict list of supported algorithms for every target, where most of them will be in common code
FYI, I have already started prototyping it. But active development will start closer to June.
As for now, I’ve started prototyping based on APIs provided out of the box + openssl:
• jvm - use jdk javax.crypto with future possibility of using openssl crypto library via jni/jextract
• js - separate implementations per browser and nodejs
◦ nodejs - use builtin crypto module - still TBD how to provide typings, kotlinx.nodejs isn’t maintained, may be just dukat will be enough
◦ browser - use window.crypto - still discovering, how much it have builtin, may be openssl via wasm will be also possible there
• darwin (macos, ios, etc) - use CoreCrypto, which is available out of the box, but also allow to use openssl via cinterop
• mingw - use CNG (https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal) - available out of the box, API is very flexible, also openssl via cinterop
• linux - no out of the box cryptography, so only openssl via cinterop for now
For openssl BTW, there will be both dynamic (linux/macos/mingw/jvm) and static(all platforms) variants to make it possible to not require installing on openssl on desktop if its not available
Ability to contribute other crypto engines of course will be possible!
If someone will want to work on it with me, please ping me in DMP.S. I have now only mac with M1 and as so, it will be hard for me to test mingw CNG implementation, so If someone help with it, it will be super useful!
4 months ago
Wow, that sounds impressive! Some feeedback:
• Instead of supporting all platform-APIs it could be easyier to just use libcrypto/openssl on all platforms. I did something similar here: https://gitlab.com/benkuly/trixnity/-/tree/main/trixnity-olm - it could be possible to share most of the code for the wrappers (I did this in the link in olmLibraryMain to share native and JVM/JNA platform).
• JVM: maybe JNA is a bit easyier to maintain, because it doesn't need to write C/C++-Code and it has the ability to load binaries from jar
4 months ago
Openssl will be available on all native platform from start. As for JVM, it's not the best choice, as distributing native libraries on JVM isn't so easy - we need to built openssl(libcrypto) for windows/linux/macos + 4 android targets. As for android, it's easy to distribute with AAR, but for JVM we need to put then built libs for several hosts this will significantly increase size.
So for JVM preferred way is to use JDK provider, but with later possibility to use openssl via jni/jna/jextract.Regarding JNA:
it's performance isn't so good as I know. JNI is hard to write, but it's faster, and looks like there will be small amount of code, need to be mapped, so it's possible (example of some opensource hash mapping - https://github.com/sfuhrm/openssl4j/blob/master/openssl4j/src/main/c/openssl4j_messagedigest.c)
Also with jextract (when it will be stable and available) we will have both performance and easy native library useRegarding Platform libraries:
Even if openssl is easy to install, and often available on host machines, IMO there should be possibility to use library with less dependencies out of the box.
Other thing is iOS - why we need to built and include openssl inside library, when we can use CoreCrypto that is available out of the box?
Yes, using openssl on all targets is easier from developer perspective, but harder from user
I would love to see a Kotlin only common implementation, but this would take more time and requires good tests!
Personally, I would "just" need JWT for Ktor native.
Ideally, this library is provided by JetBrains and will be a official kotlinx lib