On 4/2/15 1:47 PM, Duncan Jones wrote: > On 18 March 2015 at 15:47, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 3/18/15 5:57 AM, Duncan Jones wrote: >>> Hi everyone, >>> >>> I would like to begin work on a new sandbox component, Commons Crypto, >>> that makes it easier for developers to use crypto from the standard >>> Java libraries. The component would have two goals: 1) To make it >>> harder for users to make typical crypto errors, 2) To make it easier >>> to perform common crypto tasks. Some select examples are below: >>> >>> Typical errors to avoid: >>> - Weak conversion of passwords to keys. >>> - Specifying algorithms that rely on system defaults. >>> - Bad conversions of ciphertext to strings. >>> - Encryption/decryption of strings without charsets. >>> >>> Common tasks that could be easier: >>> - Specifying typical algorithms without figuring out >>> "AES/CBC/PKCS5Padding". >>> - Working with X.509 certificates >>> - Generating keys (particularly using password derivation). >>> >>> The scope of this library would be limited to the most commonly used >>> algorithms, key sizes, etc. The goal is to satisfy 80-90% of potential >>> use cases with a really well documented, compact library. Given that >>> crypto is confusing to many, documentation will be exceptionally >>> verbose. >>> >>> Two existing open-source libraries might spring to mind when >>> considering this proposal: BouncyCastle [1] is a well-known crypto >>> library with a Java implementation. However, this has different goals, >>> namely to implement actual crypto algorithms. Commons Crypto, by >>> contrast, is focussed on working with existing JDK implementations. >>> JASYPT [2] is another library aimed at simplifying use of encryption, >>> yet in my mind it goes too far, focussing only on password-based >>> encryption, with limited control over how that's carried out. >>> >>> If no-one objects, I'll begin work on this component, asking the Infra >>> team to create a new Git repository. Before committing any code, I'll >>> follow the instructions at [3] to ensure this project is compliant >>> with US Export Control Laws. >>> >>> Comments, thoughts and objections very welcome. >>> >>> Kind regards, >>> >>> Duncan >>> >>> >>> [1] https://www.bouncycastle.org/java.html >>> [2] http://www.jasypt.org/ >>> [3] http://www.apache.org/dev/crypto.html >> +1 to the idea. Fits nicely into Commons, IMO. Also have a look >> and maybe see if collaboration might be possible with Apache Shiro, >> which has a nice embedded, separately packaged crypto lib with sort >> of the same flavor as what you are describing (though probably more >> low-level). And have a look at the already existing, but more >> limited scope (and really just BC wrapper) OpenPGP already in the >> sandbox. > Thanks for pointing out Apache Shiro - this seems quite interesting; > not sure how I missed it. They are certainly aiming to achieve similar > goals with their Cryptography component [1]. > > Perhaps it might be better for me to contribute to that project > instead. I need to get stuck into their API a little more deeply to > see what's available versus my concept for Commons Crypto. > > Sorry for long delay in response, my mail filters are too aggressive > and I thought nobody had responded! > > Duncan > > [1] http://shiro.apache.org/cryptography-features.html
Of course you - and they - are welcome to carve the Shiro crypto lib out and move it here. That's how some of our current components were born. Phil > >> Phil >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
