Supported Algorithms, Operations, Providers

[whyoleg]

The current issue is just a dashboard for all algorithms/operations/providers supported or planned to be supported by the library. Status is updated after release where specific item is implemented. List is ordered only by release version and doesn't represent priority in which new items will be implemented.
Feel free to comment if you are missing something from or outside the list!

For detailed information about which provider support which algorithms please consult documentation: https://whyoleg.github.io/cryptography-kotlin/providers/

Status is provided in format of [ ] when it’s not implemented and [x] (X.Y.Z) when it’s implemented in version X.Y.Z

Algorithms

• (0.1.0) MD5 (hash) - LEGACY
• (0.1.0) SHA1 (hash) - LEGACY
• (0.1.0) SHA256, SHA512 (hash)
• (0.1.0) HMAC (mac)
• (0.1.0) AES-CBC (cipher)
• (0.1.0) AES-GCM (cipher)
• (0.1.0) RSA-OAEP (cipher)
• (0.1.0) RSA-PSS (signature)
• (0.1.0) ECDSA (signature)
• (0.2.0) SHA224, SHA384 (hash)
• (0.2.0) SHA3 family (hash)
• (0.2.0) RSA-PKCS1-V1.5 (signature)
• (0.3.0) AES-CTR (cipher)
• (0.4.0) ECDH (key agreement)
• (0.4.0) PBKDF2 (prf)
• (0.4.0) HKDF (kdf)
• (0.4.0) AES-ECB (cipher) - LEGACY
• (0.4.0) RSA without padding (cipher/ signature[?]) - LEGACY
• (0.4.0) RSA-PKCS1-V1.5 (cipher) - LEGACY
• (0.5.0) CMAC (mac)
• (0.5.0) RIPEMD160 (hash)
• AES-KW (key wrap/unwrap)
• ChaCha20-Poly1305 (stream cipher)
• Agron2 (prf)
• scrypt (prf)
• brcypt (prf)
• Blowfish (cipher)
• Blake (hash)
• SHAKE (hash)
• EdDSA (signature)
• XDH (key agreement)
• DH (key agreement)
• DHKEM (kem)
• MLDSA (signature) - PQC
• MLKEM (kem) - PQC
• TOTP/HOTP (otp)

Operations

• (0.1.0) Hashing
• (0.1.0) Cipher and AEAD Cipher
• (0.1.0) Signature generation and verification
• (0.4.0) Key agreement
• (0.4.0) Key derive (kdf/prf)
• Key wrap/unwrap
• Hybrid Encryption
• KEM (Key encapsulation mechanism)
• OTP (One Time Password) support

Providers

• (0.1.0) WebCrypto
• (0.1.0) Apple
• (0.1.0) JDK
• (0.1.0) OpenSSL3
• (0.5.0) CryptoKit
• Windows CNG
• AWS/GCP KMS provider
• BorringSSL (optional, in addition to openssl)
• NodeJS engine
• OpenSSL3 KMP (JVM , may be JS/Wasm)
• wasi-crypto or via component model

[dominikkv]

Hi, I have a project which requires AES-ECB for iOS and Android. It would be great if you could implement this mode. Thanks!

[whyoleg]

Hey @dominikkv, could you please describe a use case for AES-ECB just in case?

[dominikkv]

Hi @whyoleg, in this project we communicate with a bike lock via BT LE. During the authentication process the lock sends us a challenge, which we have to decrypt, modify, and encrypt again, to send the result back to the lock.

Thanks for considering the implementation of AES-ECB!

[whyoleg]

Thanks @dominikkv!
I will add AES-ECB to plans, though, as this algorithm is some kind of "legacy/unsafe", I'm not sure yet, what will be the best way to show this when using the library.
Still, I will try to come up with something!

[dominikkv]

Hi @whyoleg, one idea would be to annotate the function / class with a "Unsafe to use" opt-in annotation: https://kotlinlang.org/docs/opt-in-requirements.html

[whyoleg]

Yeah, that't the simplest way here...
But there are some usability issues with opt-in:

• the declarations are still present in completion
• IDEA will allow to opt-in into this in a one click - not really convenient as AFAIK users are frequently ignoring what annotation say
• API reference will still have all those declarations in one place

On current moment I thinking about introducing of additional module for this, so that if it's REALLY needed it will be possible to add module and so use those algorithms.
But I'm not yet finalised design here, so, thanks for your comment!

[huskcasaca]

Hi @whyoleg, I'm planning to use this lib in my crypto lib but some critical hashes and functions are missing. Can we add RIPEMD160 and prioritize it? SHA256, RIPEMD160, PBKDF2 and scrypt are fundamental hashes in Bitcoin. It will be really nice to have these and making this lib able to be used a cryptocurrency lib.

[whyoleg]

Hey @huskcasaca, RIPEMD160 is rather specific hash and is not supported out of the box even in JDK (only with BouncyCastle). So may be it will be much simpler to use it from somewhere else. I do think, that we can try to implement RIPEMD160 from scratch, but I would like to avoid introducing from scratch things as much as possible.
Also, what do you mean by prioritize it? Just implement it earlier or something else?

PBKDF2 will be supported in upcoming release. The story with scrypt is similar to RIPEMD160.

Also, I do have a plan to introduce better integration with BouncyCastle (via separate provider), so that we could have BouncyCastle+openssl combination for Android+iOS cases at least. No dates for when this will happen.

If you are willing to contribute something, please create a separate issue and let's discuss possibilities

[huskcasaca]

@whyoleg Yes, it would be nice to implement it earlier since the most widely used scenarios for crypto libraries are for cryptocurrencies, and RIPEMD160 and PBKDF2 are key algorithms for that.

I will do some research first for future contributions.

[Bingoliallen]

KMP platform IOS need the AES-GCM，how to do?

[whyoleg]

KMP platform IOS need the AES-GCM，how to do?

Hey, you just need to add dependencies as shown here and then you can take a look on AES-GCM example on how to use library APIs

[sgozdzik]

KMP platform IOS need the AES-GCM，how to do?

Hey, you just need to add dependencies as shown here and then you can take a look on AES-GCM example on how to use library APIs

Unfortunately at this moment AES-GCM is not supported by iOS provider, do you plan to add it in near future?
Thanks!

[ajeeb-bin-hamid]

Hi @whyoleg
Thank you for creating this fantastic library! I was wondering if there are any plans to add support for AES-GCM to the iOS provider. Since AES-GCM has become the recommended way for AES encryption, having this feature would be a great addition.