commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Date Thu, 02 Apr 2015 21:34:33 GMT
On 4/2/15 1:47 PM, Duncan Jones wrote:
> On 18 March 2015 at 15:47, Phil Steitz <phil.steitz@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message