search

whyoleg / cryptography-kotlin

Kotlin Multiplatform cryptography / crypto library
https://whyoleg.github.io/cryptography-kotlin/
Apache License 2.0
287 stars 18 forks source link

Supported Algorithms, Operations, Providers #15

Open whyoleg opened 7 months ago

whyoleg commented 7 months ago

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

Operations

Providers

dominikkv commented 7 months ago

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 commented 7 months ago

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

dominikkv commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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