I honestly like the idea of renaming Cipher to StatelessCipher and keeping everything else as is. This would allow 1.0 to ship faster while being sufficiently descriptive in the name for people that are doing crypto to understand the limitations of the existing Cipher.
Allan On Wed, Mar 31, 2010 at 3:03 PM, Les Hazlewood <[email protected]>wrote: > Allan was kind enough to refactor our one and only BlowfishCipher > implementation into 2 classes: AbstractCipher and BlowfishCipher to > allow for more algorithms easily. This allowed him to easily create a > new AesCipher implementation that hasn't been committed yet. > > This led me to think about how to ensure AbstractCipher would work for > not just Block Cipher algorithms (Blowfish, AES, TripleDES, etc), but > for asymmetric algorithms as well, which led me deeper down the path > in to the javax.crypto.Cipher guts. > > Short story: The javax.crypto.Cipher (a class, not an interface) is a > stateful mechanism. The Shiro Cipher interface forces a stateless > implementation. > > This poses problems if people want to use Shiro as a general > cryptography framework: It won't work well for large data sets or > streaming data (videos, networking, large documents, etc) of any kind. > That the method signatures require the entire byte array to be in > memory limits its usefulness to smaller encryption/decryption tasks. > This is not good for a long term solution. > > Refactoring things now, so close to 1.0 would probably delay things > another few days. I think maybe instead, it would be better to rename > the existing Cipher interface to StatelessCipher and keep what we have > in place. Then, when we have the time to work out a cleaner > abstraction, we can then create a 'real' Cipher interface that can > handle stateful operations in a clean manner. > > Or maybe I just spend a few days and put together a more robust > permanent solution. > > Thoughts? Recommendations? > > Thanks, > > Les >
