You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Duncan Jones <dj...@apache.org> on 2015/03/18 13:57:56 UTC
[PROPOSAL] Create new sandbox component "Commons Crypto"
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [PROPOSAL] Create new sandbox component "Commons Crypto"
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: Phil Steitz [mailto:phil.steitz@gmail.com]
> Sent: Wednesday, March 18, 2015 11:47
> To: Commons Developers List
> Subject: Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
>
>
> 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.
We frequently do the same here, and I would be willing to contribute (CLA on file) some of our code or write new for the effort.
Most of our work is with x509 processing.
-Jason
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Posted by Siegfried Goeschl <si...@it20one.com>.
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 <ph...@gmail.com> wrote:
>
> On 4/2/15 1:47 PM, Duncan Jones wrote:
>> On 18 March 2015 at 15:47, Phil Steitz <ph...@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
>
Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Posted by Phil Steitz <ph...@gmail.com>.
On 4/2/15 1:47 PM, Duncan Jones wrote:
> On 18 March 2015 at 15:47, Phil Steitz <ph...@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
Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Posted by Duncan Jones <dj...@apache.org>.
On 18 March 2015 at 15:47, Phil Steitz <ph...@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
>
> 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
Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Posted by Phil Steitz <ph...@gmail.com>.
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.
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
Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
Posted by Gary Gregory <ga...@gmail.com>.
+1, nice thought.
Gary
On Wed, Mar 18, 2015 at 5:57 AM, Duncan Jones <dj...@apache.org> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory