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 bgiles@coyotesong.com
 designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <87eh7cmeoz.fsf@v35516.1blu.de>
References: <87r4bcd1qj.fsf@v35516.1blu.de> <526782F2.4060905@apache.org>
 <87iowomjpa.fsf_-_@v35516.1blu.de> <l485hk$h69$1@ger.gmane.org>
 <87eh7cmeoz.fsf@v35516.1blu.de>
From: Bear Giles <bgiles@coyotesong.com>
Date: Wed, 23 Oct 2013 06:42:15 -0600
Message-ID: 
 <CALBNtw6S78RG2VNpd4v1V5XLO92L9Wr06aqHQ_jc6nJybCghvQ@mail.gmail.com>
Subject: Re: [compress] Strong Crypto in Tests
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=20cf3010e4df05303704e967da92

--20cf3010e4df05303704e967da92
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Should that be PKCS7Padding? Or would that be worse - I don't recall if
it's one of the "must have" paddings in the spec.

http://crypto.stackexchange.com/questions/9043/what-is-the-difference-betwe=
en-pkcs5-padding-and-pkcs7-padding

In practice it's unlikely that a software-based crypto provider will be so
pedantic that it throws an exception if you try to use PKCS5 with a 256-bit
cipher but I'm not sure if that's true if it's a hardware-based crypto
provider. Anyone who springs for hardware will probably want something that
strictly complies with the spec and PKCS5 is only defined for 64-bit
ciphers.

Bear


On Wed, Oct 23, 2013 at 5:03 AM, Stefan Bodewig <bodewig@apache.org> wrote:

> On 2013-10-23, J=F6rg Schaible wrote:
>
> >  boolean supportedKeyLength(int keyLen) throws NoSuchAlgorithmException
> >  {
> >    if (Cipher.getMaxAllowedKeyLength("AES/ECB/PKCS5Padding") < keyLen) =
{
> >      System.err.println("WARNING: " + getName()
> >        + " not executed, environment does not support " + keyLen
> >        + "-bit keys for AES");
> >      return false;
> >    }
> >    return true;
>
> Looks a lot nicer than my "catch Exception" approach, thanks.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--20cf3010e4df05303704e967da92--