commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <siegfried.goes...@it20one.com>
Subject Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Date Fri, 03 Apr 2015 10:42:45 GMT
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.steitz@gmail.com> wrote:
> 
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message