-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it stateless #2
Comments
Right, but my goal was to have something different. The web is full of stateles and procedural crypto libraries, while at the same time, it seems, people like working with objects. I also don't think I'd be able to provide automatic key generation in a stateless library. |
Well, that leaves me 2 thoughts:
I get what you're trying to do. And I'm not saying it's wrong. I'm just saying I'd recommend not doing it that way (as it makes it less useful and harder to reason about).
I don't think you should provide automatic key generation. Key generation is something that shouldn't really happen often, and shouldn't happen on a web thread (IMHO) simply because there are enough concerns that need to be addressed. But fair enough. |
Well, I do intend to write a more flexible library that would most likely be stateless. Here I wanted something that every newbie could use by taking all responsibilities away from them and sqeezed into a few methods. This would include online key generation, becase that's practically what every newbie would do, so I figured I could at least make it more sane than using a simple password (which is another thing a newbie would do). I understand your concern of course and with the addition of a key store, I might achieve the same goals. But I fear that the moment that this library grows beyond a single class and/or file, it'd no longer be that user-friendly. :/ |
I strongly recommend that you make the class stateless rather than statefull as you have it now.
Basically, don't pass in input to the constructor, but instead have discrete
encrypt($text)
anddecrypt($text)
methods.This will make it far easier to reason about what's going on, because object state doesn't need to be considered. And separating encryption flows from decryption flows will also provide clarity.
And as a stateless object, it can be re-used (which means things like setup can be shared across encryption/decryption runs).
The text was updated successfully, but these errors were encountered: