gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Crypto] More keyrings, PBE.


From: Casey Marshall
Subject: Re: [GNU Crypto] More keyrings, PBE.
Date: Thu, 02 Oct 2003 17:48:15 -0700
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Raif" == Raif S Naffah <address@hidden> writes:

Raif> hello Casey,
Raif> On Thu, 2 Oct 2003 01:59 pm, Casey Marshall wrote:
>> (It looks like the internet ate my previous message, so this is
>> kind of a re-send)
>> 
>> I've just checked in JCE adapters for password-based encryption,
>> and a SecretKeyFactory interface to the PBKDF2 function. We now
>> have ciphers in the GNU-CRYPTO provider with the following pattern:
>> 
>> PBEWithHMac<HASH>And<CIPHER>
>> 
>> For each message digest and cipher.
>> 
>> Also new is a KeyStore adapter for GNU keyrings, and I have been
>> able to use `keytool' to read a public keyring. Attached is an
>> example public keyring with the same contents as the `cacerts' file
>> distributed with the JDK.

Raif> good news!  i suggest you announce this on the Classpath
Raif> mail-list.  i'm planning on updating the home page this weekend,
Raif> and in the course of doing so i'll include the draft document
Raif> about the specification; this way we may get more participation.

Also, since I think I haven't mentioned it yet: the draft is now in
CVS in the file docs/draft-marshall-gnu-keyring.nroff. This is
RFC-style nroff source.

Raif> in parallel, may be we can finalise the issue i raised about the
Raif> optional packets.

My intention with the optional packet types (non-password encrypted
and authenticated) was to allow such things to be used in site- or
application-specific contexts. That is, normal applications such as
the KeyStore implementation just ignores these packets, since there
are no methods to decode these packets in the API to do so.
Applications where a password-based encoding is inconvenient or
impossible can use the alternatives.

Maybe it would be better to state in the spec that these optional
packets must be parsed (or skipped), but their contents need not be
decoded.

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE/fMcLgAuWMgRGsWsRAqUeAJ9fBbSajUm00b8oA038o4fqqfy7bgCdG8gf
cc1VeY2fXtpehiIetlXmN3Q=
=2tCK
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]