Re: [GNU Crypto] PBE

[Casey Marshall]

Raif S. Naffah wrote:
> 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?

Yup.

> 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).

On reflection this seems now to be impractical to fit into the API 
(would PBECipher implement IBlockCipher? IMode? Would it contain its own 
Mode and Padding intsances? etc.), and an Assembly (as you metion below) 
would likely work better.

> >   * 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!

Yeah. I just thought having the KDF on its own would fit the current API 
better -- e.g. most things are separate, and the programmer using the 
library has to be smart about what she does with the pieces; so if she 
wants to implement "PBEwithSHA1andTripleDES-CBC-PKCS7" she needs to 
create all the pieces and use them together properly. This is possibly a 
nuisance, possibly a barrier against bad programming.

But...

> 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.

This is a better idea, I think. It keeps things seperate and modular, 
but provides the simple interface to complex constructions.

> > 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.

A boolean flag, e.g. 'ALLOW_SHORT_KEYS' would allow those who know what 
they're doing to use short keys, but still prevent short keys from being 
used by default.

Cheers,

--
Casey Marshall || address@hidden

pgpLlhEH0kyHH.pgp
Description: PGP signature