commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Jones <>
Subject Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Date Thu, 02 Apr 2015 20:47:31 GMT
On 18 March 2015 at 15:47, Phil Steitz <> 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]
>> [2]
>> [3]
> +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!



> Phil
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message