Re: [GNU Crypto] PBE

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello Casey,

On Sunday 09 March 2003 08:53, Casey Marshall wrote:
> Hi,
>
> I was looking into implementing password-based encryption (PKCS #5)
> in GNU Crypto -- mostly in relation to the encrypted JAR file stuff
> mentioned earlier -- and wanted to get some opinions about how to
> implement such a thing.
>
> So far I've come up with the following possibilities:
>
>    * Create a PBECipher class that implements IBlockCipher (or IMode)
>      that takes in its attributes map additional parameters for the
>      password and salt, and generates the key and IV within the
> init() method.

i take it that this PBECipher would be what rfc2898 refers to as PBES2?

if it is the case; then PBKDF2 would be the underlying primitive to 
generate the session key from the user's key material (P, S, and c).  
PKDF2 can also be implemented as a prng, which would throw a 
LimitReachedException if/when '(2^32 - 1) * hLen' bytes have been 
generated --hLen being the block length of the underlying PRF (eg. 
HMAC-SHA-1).


>    * A separate class (and a surrounding interface) that just
> implements the key derivation function, leaving it up to the
> programmer to wrap the generated bytes into a form suitable for
> sending to a cipher or MAC.
>
> So the question here is to have a simpler API, or a simpler
> implementation. I am leaning towards the second, for its flexibility.

as rfc2898 points out, PBSE2 is a Cipher+Mode+Padding; the KDF is just 
how the session key gets generated!

our API as it is today, unlike the JCE, does not handle the combination 
of Cipher+Mode+Padding.  may be this is a good opportunity to have a go 
at it.  the JCE alternative works but is limited.  what would be better 
is an Assembly type object that (a) allows for simple cipher + mode + 
padding combos, as well as (b) more complex ones where assembled 
elements may themselves be Assemblies.


> Also: PKCS #5 v.2 seems to require a MAC that can take keys shorter
> than the digest length, which is strictly prohibited in our current
> HMAC implementation.

true.  this is in accordance with the wording of section 3 in rfc2104. 
to wit:

"3. Keys

   The key for HMAC can be of any length (keys longer than B bytes are
   first hashed using H).  However, less than L bytes is strongly
   discouraged as it would decrease the security strength of the
   function....
"
L in the above is the output length of the hash function, and B it's 
blocksize.

however, in order to allow the use of the HMAC for PKCS#5 v2 we can add 
a "feature" in the initialisation map that would relax this constraint.


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+bGRg+e1AKnsTRiERA/ncAJ98TlTKe/Q+eds4Ol5hDlDPrKbYgACfbcW4
6dJWtFTrf/D8rXW6XzyfSLk=
=CWhz
-----END PGP SIGNATURE-----