Re: [GNU Crypto] PBE

[Raif S. Naffah]

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

hello Casey,

On Wednesday 12 March 2003 09:13, Casey Marshall wrote:
> Raif S. Naffah wrote:
> > On Sunday 09 March 2003 08:53, Casey Marshall wrote:
> >> ...
> >>I was looking into implementing password-based encryption (PKCS #5)
> >>in GNU Crypto...
>
> > 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.

...but PBKDF2 can still be implemented as a prng type; right?


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

i'm glad you agree :-)

i'll work on a proposed API this weekend and post it here, but if you 
beat me to it i wont be offended ;-)


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

i suggest the name of this boolean key to be: USE_WITH_PKCS5_V2 or 
something similar that explicitly mentions PKCS#5 v2.  this is because 
the designers of pkcs#5 v2 are assumed to have analysed the 
consequences of allowing shorter keys and found them to be safe.  of 
course, anybody using an hmac, even outside the context of pkcs#5 v2, 
can set this property to "true" but then, not only will they be doing 
this at their own risk, they will also be (in a way) mis-using the 
purpose of this feature.


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

iD8DBQE+b30g+e1AKnsTRiERAybLAKDgVWR6Aj4ETOHsPsHlbYMJyM3cqwCg5ZMs
zwhYin0pSdw7Bidz8H318MI=
=l07R
-----END PGP SIGNATURE-----