Re: [GNU Crypto] Passwords Immutable?

[Bryan Hoover <bhoover@xxxxxxxx>]

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

Sorry so long in responding to this -- had to take a unicode, and bit
manipulation  learning, and review detour.  This has yielded however,
more accomodating unicode char[] to utf-8 conversion code -- presently
encapsulated in SensitiveData, and used by Password as a call to super.
Though this design may be found lacking (see below) as I'm not sure
about how to init Password's char[] when it's parent, SensitiveData
byte[] constructor is used, instead of its (Password's) char[]
constructor.

> Bryan> Ignoring PLAIN is reasonable (though a wee bit discriminatory
> Bryan> :)).  But there's the MD5 mechanism too.
>
> Bryan> My thinking is that any data structure that a shared secret
> Bryan> goes into, ought to be a decendant of DestroyableObject.  In
> Bryan> this light, that concatenated user info/password ought to go to
> Bryan> Password construction together.

I note here, that I was mistaken about the MD mechanism -- concatenation
is after the
password, and other data are hashed, so passwor'd not stored 'in the
clear'.

> I like the idea of having a byte-oriented class underlying Password
> (which then just adds char support). `SecureData' might be a misnomer
> too, however ;) I mean, we don't want to imply that storing data into
> this class secures it in any meaningful way. `SensitiveData' might be
> a better name.

Which would seem to imply simply moving the byte oriented stuff
presently in Password, to SensitiveData (which, as indicated, I've,
preliminarily at lease, done).

Though this presents a slight design problem in terms of what to do with
Password construction from byte[] -- that is, if SensitiveData
encapsulates byte[], and Password encapsulates char[], *and* byte[]
versions of Password, which of these two classes handles Password's
byte[] password to char[] password conversion?  Eeek!

Perhaps a simpler more natural approach than that implied above (I'm
thinking, Password byte[] constructor passthroughs to super,
SensitiveData -- though this may indeed be the most natural approach)
will present itself upon taking a step back (from my unicode foray,
brain damage :)), but that's the way I see it right now.

The more I think about it, the more comfortable I am with Password
byte[] constructor passthroughs -- it's still a bit like, 'man, what a
lot of constructors!' -- I'd just have to add the passthrough
constructors, and a utf-8 to char[] conversion routine to complete the
implementation.

Also, may as well move the char[] to byte[], byte[] to char[] into a
separate unicode oriented class also.  Since Password would be tied to
SensitiveData by inheritence, may as well be encapsulated by
SensitiveData, but public (protected?) so Password could use the byte[]
to char[] conversion.

What do you think?

Bryan

> - --
> Casey Marshall || csm@xxxxxxx
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
>
> iD8DBQFAmC/GgAuWMgRGsWsRAsU/AKCNsNsK50r7K7+E1/X6plC5kaOhCgCeMn3s
> whs/PhXVCMiX78TSSmXIbwk=
> =k/ow
> -----END PGP SIGNATURE-----

- --
Were I to wish for anything I would not wish for wealth and power, but
for the passion of the possible, that eye which everywhere, ever young,
ever burning, sees posibility. - (Soren Kierkegaard - Either/Or)

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

iD8DBQFAnq2c8CguVNZ0FHARAqraAJ9KCLypUl9rW7WTnM2OdwuG47YvXwCeJ+10
0ckNDFHA8fJPCXTVbx8z51g=
=KAJq
-----END PGP SIGNATURE-----


_______________________________________________
gnu-crypto-discuss mailing list
gnu-crypto-discuss@xxxxxxx
http://mail.nongnu.org/mailman/listinfo/gnu-crypto-discuss