cryptography-kotlin icon indicating copy to clipboard operation
cryptography-kotlin copied to clipboard

Published 20 hours ago • verified publisher icon whyoleg

Supported Algorithms, Operations, Providers

Open whyoleg opened this issue 1 year ago • 9 comments

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

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

Operations

  • [x] (0.1.0) Hashing
  • [x] (0.1.0) Cipher and AEAD Cipher
  • [x] (0.1.0) Signature generation and verification
  • [ ] Key agreement
  • [ ] Key derive (kdf/prf)
  • [ ] Multi-key agreement support
  • [ ] Key wrap/unwrap
  • [ ] OTP (One Time Password) support
  • [ ] Hybrid Encryption

Providers

  • [x] (0.1.0) WebCrypto
  • [x] (0.1.0) Apple
  • [x] (0.1.0) JDK
  • [x] (0.1.0) OpenSSL3
  • [ ] 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

whyoleg avatar Feb 21 '24 15:02 whyoleg

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

dominikkv avatar Mar 05 '24 10:03 dominikkv

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

whyoleg avatar Mar 06 '24 09:03 whyoleg

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!

dominikkv avatar Mar 06 '24 11:03 dominikkv

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!

whyoleg avatar Mar 07 '24 16:03 whyoleg

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

dominikkv avatar Mar 25 '24 10:03 dominikkv

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!

whyoleg avatar Mar 25 '24 11:03 whyoleg

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.

huskcasaca avatar Jul 17 '24 05:07 huskcasaca

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

whyoleg avatar Jul 18 '24 20:07 whyoleg

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

huskcasaca avatar Jul 22 '24 07:07 huskcasaca

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

Bingoliallen avatar Oct 28 '24 09:10 Bingoliallen

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

whyoleg avatar Oct 29 '24 18:10 whyoleg