[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] PBE
From: |
Raif S. Naffah |
Subject: |
Re: [GNU Crypto] PBE |
Date: |
Mon, 10 Mar 2003 21:09:35 +1100 |
User-agent: |
KMail/1.4.3 |
-----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-----