Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of garydgregory@gmail.com
 designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABeJX=3yrZp3QjPBQak6C0gAuA1anxXgodZ4y4qOLTGLfKHcOw@mail.gmail.com>
References: 
 <CABeJX=3yrZp3QjPBQak6C0gAuA1anxXgodZ4y4qOLTGLfKHcOw@mail.gmail.com>
Date: Wed, 18 Mar 2015 09:07:48 -0700
Message-ID: 
 <CACZkXPwAhvuGwwxkQJ3ds6h49YfzHCZ0M8MrT34Aj_VQE9ZX1A@mail.gmail.com>
Subject: Re: [PROPOSAL] Create new sandbox component "Commons Crypto"
From: Gary Gregory <garydgregory@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a11c37f9cda0821051192487b

--001a11c37f9cda0821051192487b
Content-Type: text/plain; charset=UTF-8

+1, nice thought.

Gary

On Wed, Mar 18, 2015 at 5:57 AM, Duncan Jones <djones@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

--001a11c37f9cda0821051192487b--