[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: [GNU Crypto] Passwords Immutable?

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[]

> 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

> 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

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?


> - --
> Casey Marshall || csm@xxxxxxx
> 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

- --
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)


This signature file is generated by Pick-a-Tag !
Written by Jeroen van Vaarsel
Version: GnuPG v1.2.2 (MingW32) - GPGrelay v0.94


gnu-crypto-discuss mailing list

[Home]     [Gnu Classpath]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]     [Red Hat 9 Bible]     [Fedora Bible]     [Red Hat 9]     [Network Security Reading]

  Powered by Linux