[Top][All Lists]

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

Re: [GNU Crypto] Passwords Immutable?

From: Casey Marshall
Subject: Re: [GNU Crypto] Passwords Immutable?
Date: Sat, 01 May 2004 23:00:27 -0700
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

Hash: SHA1

>>>>> "Bryan" == Bryan Hoover <address@hidden> writes:

Bryan> Casey Marshall wrote:
>> Actually, it would be better to be able to gracefully handle either
>> a char[] or a Password.

Bryan> And byte[] too.  Java's reflection would provide for testing
Bryan> type wouldn't it?  Could just add a utility routine or
Bryan> something somewhere to neatly encapsulate/wrap the testing
Bryan> functionality.  In C for instance, one might redefine the
Bryan> HashMap type, and overload it's property returning routine.
Bryan> But I realize I probably need to wash my mouth out with soap
Bryan> for such dirty talk :).  Just a couple initial thoughts.

This kind of sounds like something generics are good for, if I
understand you correctly. In which case, wait a little while ;)

Bryan> The big question is, do want to continue to support String
Bryan> password property?  Which I guess boils down to, how important
Bryan> at this stage of GNU-Crypto lifetime, is backward compatibility
Bryan> in terms of this aspect of the api, and are there generally,
Bryan> potentially many different programs interfacing with the lib at
Bryan> this api level.  That is, I don't imagine everyone using the
Bryan> SRP implementation for instance, is using SaslConnection to do
Bryan> so, so I would think, at least potentially, losing the String
Bryan> property parameter could be at least somewhat of an agravation.

One thing that GNU Crypto's CVS HEAD is wide open for is API changes.
This branch is the "development" branch of GNU Crypto, which will
eventually be the 2.1 series. So abandoning allowing Strings as SASL
passwords is something the world would have to deal with.

I'd like to look at the SASL spec before commiting to removing support
for Strings.

Bryan> Another thought -- an Object Password constructor, and
Bryan> reflection could handle it couldn't it?

I don't think that's necessary. There are only a handful of sensible
ways to store a password, so byte[] and char[] are probably enough.

- -- 
Casey Marshall || address@hidden
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <>


reply via email to

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