Redesign steel_crypt API with a host of new features (steel_crypt 2.0)

[jonas-zebari]

This message has been hijacked to tell you that this issue is not just about the below. Instead,
it's an issue for Steel Crypt 2.0, a comprehensive revamp of steel_crypt which factors in user feedback. If you have something to add, comment at the very end. Otherwise, monitor the project board and #22 (comment) for progress on the TODO's.

---

Original Text:

Several areas of the package use strings to determine what type of encryption, padding, etc. to use. Although each possibility is well documented I wonder if it would be more user-friendly to provide these values as enums, or perhaps named constructors?

For example, we could go from:

final aesCbc = AesCrypt('cbc');

to

final aesCbc = AesCrypt(AesMode.cbc);

OR

final aesCbc = AesCrypt.cbc(otherParams);

As a new user of this plugin I'm willing to make these changes but I wanted to know your thoughts before starting the work.

[AKushWarrior]

Ironically, I started this already.

The way I designed the classes to revolve around strings instead of enums/named constructors is terrifyingly archaic, and I've been itching to redo it for a while. What's been stopping me is the deprecated code and lack of backwards-compatibility that a new API would cause. My current solution is to publish the changes under steel_crypt 2.0.0, and add notices about the lack of backwards compatibility.

Some other tidbits that I want to include in this 'redesign':

• Named parameters: positional params with 3+ positions is untenable.
• switch statements instead of if (mode == x) {} else if (mode == y) {} else if (mode == z) {} ... else {}

However, you don't have to do these changes. I'll do them myself; I already have them started.

@jonas-zebari TLDR: I've decided I definitely want this and some other changes done to the API. I'll be doing those personally...

[AKushWarrior]

I'm turning this into a general issue for steel_crypt 2.0 redesign progress. Post any updates/PRs here...

[jonas-zebari]

Fantastic! Thanks for the response.

[AKushWarrior]

New updates for steel_crypt 2.0:

• I will also include "raw classes" (rawAesCrypt, rawHashCrypt, etc.) that work with Uint8Lists. This is as per Why enforcing base64 encoding? #26.
• I will include ECC as per could you add ECC  #24.

[denis-evteev]

I think that for the PassCrypt version 2.0 one can make the following set of constructors:

PassCrypt(AlgoNameEnum algoName, [CipherParameters cipherParameters])
//…

PassCrypt.pbkdf2([Pbkdf2Parameters pbkdf2parameters])
//…

PassCrypt.scrypt([ScryptParameters scryptParameters])
//…

In this case one could tweak the hashing parameters, including salt, number of iterations (for PBKDF2), cost (for Scrypt), etc. If no parameters are provided, then existing defaults with no salt could be applied.

[AKushWarrior]

That makes sense. I have them set to 'sane defaults', but I can just make those the default values.

The other thing I could to is to make each param of ScryptParameters/Pbkdf2Parameters a named parameter in the login. That way, users could choose what params to edit, and the rest would be the defaults that I choose.

Will edit a code snippet when I'm at my computer.

[AKushWarrior]

I should formalize base64 as the method for encoding/decoding everything (in the encoded/non-raw classes).

In raw classes, obviously, everything is Uint8Lists.

[AKushWarrior]

I'll be updating this with the latest progress...

If you prefer a project board view, https://github.com/AKushWarrior/steel_crypt/projects/1. I personally think this is less cluttered.

@denis-evteev @jonas-zebari @cailetech @note8g2018 @s349856186 and everyone else who has issues, monitor this checklist.

Progress Report/TODO:

• Make everything use switch statements and enums (This issue)
• Unions/Named constructors for PassCrypt() and MacCrypt() (This issue)
• Make all encoded classes use base64 (Related to How to do CBC-PKCS7 and iv=MD5(key)? #23)
• Used named instead of positional parameters (This issue)
• Add parameter for AAD to AesCrypt() (How to decrypt aes-256-gcm in PHP OpenSSL? #11)
• Look into adding Poly1305 (Personal)
• Also add ChaCha20-Poly1305 (Personal)
• Add ECC asymmetric encryption (could you add ECC  #24)
• Add Raw Classes dealing in Uint8Lists (Why enforcing base64 encoding? #26)
• Redo all documentation to be more specific (Personal)
• Host new docs website on GitHub Pages (Personal)

[AKushWarrior]

I should add Poly1305 and ChaCha20-Poly1305, because those are becoming standardized.

[AKushWarrior]

I've started writing a bootstrapped website which will host the new docs. Eventually, this will go on Github Pages:

[AKushWarrior]

[AKushWarrior]

@denis-evteev @jonas-zebari @cailetech @note8g2018 @s349856186 Many of the features have been published in a 2.0 beta. See https://pub.dev/packages/steel_crypt.

The checklist above is still where I'm documenting progress.