Redesign steel_crypt API with a host of new features (steel_crypt 2.0) about steel_crypt HOT 12 OPEN

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

from steel_crypt.

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

from steel_crypt.

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

from steel_crypt.

Fantastic! Thanks for the response.

from steel_crypt.

New updates for steel_crypt 2.0:

• I will also include "raw classes" (rawAesCrypt, rawHashCrypt, etc.) that work with Uint8Lists. This is as per #26.
• I will include ECC as per #24.

from steel_crypt.

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.

from steel_crypt.

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.

from steel_crypt.

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

In raw classes, obviously, everything is Uint8Lists.

from steel_crypt.

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 #23)
• Used named instead of positional parameters (This issue)
• Add parameter for AAD to AesCrypt() (#11)
• Look into adding Poly1305 (Personal)
• Also add ChaCha20-Poly1305 (Personal)
• Add ECC asymmetric encryption (#24)
• Add Raw Classes dealing in Uint8Lists (#26)
• Redo all documentation to be more specific (Personal)
• Host new docs website on GitHub Pages (Personal)

from steel_crypt.

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

from steel_crypt.

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

from steel_crypt.

from steel_crypt.