Hi folks, sounds good to me
* it would be appreciated to have no additional dependencies, e.g. BC library mismatch can be painful * one point to keep in mind is https://www.apache.org/dev/crypto.html <https://www.apache.org/dev/crypto.html> * I wrote some crypto-related code over the years so I won’t be a big help but I’m interested in the project * I fully agree with the documentation aspect - crypto is somehow self-defending :-) Cheers, Siegfried Goeschl > On 02 Apr 2015, at 23:34, Phil Steitz <phil.ste...@gmail.com> wrote: > > 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 >
