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

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

Re: [GNU Crypto] Passwords Immutable?


From: Bryan Hoover
Subject: Re: [GNU Crypto] Passwords Immutable?
Date: Sat, 01 May 2004 21:27:28 -0400

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

Casey Marshall wrote:
> Bryan> Done.  And thanks for the tips.  I received 'assignment process
> Bryan> complete' notification from Ted (copyright clerk) yesterday.
>
> Bryan> Password.java, and unified diff for changes to SRPClient, and
> Bryan> SaslConnection attached.
>
> Bryan> The diff is relative to gnu-crypto/source directory.
>
> Merged into CVS HEAD. A couple of comments:

That's great!  I'm proud to contribute to this project.

>    - It's our convention to not use redundant modifiers and
>      declarations; this includes `throws' clauses for unchecked
>      exceptions (although, they should be described in a address@hidden'
>      entry in the javadocs, if it is a public or protected method).
>
>    - `doDestroy' shouldn't throw a DestroyFailedException, since it is
>      a serious bug if an exception is thrown when erasing passwords
>      (i.e., doDestroy should never fail in this class).
>
>    - `password' and `bPassword' are declared as `final', and they are
>      initialized in the constructor (there really wasn't any need for
>      the init* methods).

Language ignorance is what that was -- thanks.

>    - I put Password into the package gnu.crypto.auth. I'm certain that
>      this class will be useful in other places. The next thing to do
>      is replace char arrays with Password wherever else appropriate.

One small thing -- I noticed a change in the SRPClient password
initialization so that it expects the password property to contain a
char[] array rather than a Password object, as I had put it.  I was
wondering what your thinking was on that.  Either way -- whether change
to char[] or Password, from String -- from the gnu-crypto lib client
perspective, api interfacing would need to be changed anyway (short of
some other api work around, or addition).

SaslConnection can be easily changed to accomodate a char[] array hash
map property (unified diff attached), though as it stands, my previous
patch has it creating a Password, and setting the hash map property to
that (with resultant illegal cast exception reliably reported :)).

It boils down to an api question -- should callers use a Password, or
char[]?, taking things into consideration like:  What about Password's
byte[] constructor?  Should the hash map provide for a byte[] password?
That sort of thing.

On unicode accomodation -- I left that out because there was an
SRPClient code comment about staying compatible with C language
clients.  In any event however, as I understand the unicode standard,
this would require an additional parameter to indicate the encoding
type?  That is, I assume unicode standard then, could be accomodated
with an additional constructor, while ascii remains the unparameterized
default.

Hopefully I havn't misunderstood, or overlooked anything.

> Cheers,

Absolutely, and thanks for being so helpfull,

Bryan

> - --
> Casey Marshall || address@hidden
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
>
> iD8DBQFAlBOXgAuWMgRGsWsRAgtsAJwIHf57svCdMp0sTUbWg5N4OOGRBgCbBhv7
> bCqtWwSEY/Z/uiW9IZzF8Gc=
> =DjJW
> -----END PGP SIGNATURE-----

- --
Nothing in the world has more potential for beauty than woman.  Nothing
has more potential to destroy it, than the world. - (Anonymous)

http://www.wecs.com/content.htm

This signature file is generated by Pick-a-Tag !
Written by Jeroen van Vaarsel
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=pick-a-tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32) - GPGrelay v0.94

iD8DBQFAlE6E8CguVNZ0FHARAkuEAJ9LV49a01xkT4hz/ehb1rq9Eem5DQCeNTj8
vDe1L4Vmqu7PWtlyZmhAGf8=
=5VbP
-----END PGP SIGNATURE-----

Attachment: SaslConnection.patch
Description: application/unknown-content-type-patch_auto_file

Attachment: SaslConnection.patch.asc
Description: Binary data


reply via email to

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