Re: [Jsdsi-devel] Algorythm names

[Sameer A. <aj...@cs...>]

I'm not familiar with cvs branches, but if this is a good solution for
you, go for it.  I won't have a chance to look at JSDSI for about two
months (dissertation crunch)!  However, if your algorithm change is
compatible with older versions (won't break existing code), then there's
probably no harm in checking it in.

Sameer

> Hi,
>
> Don't suppose any of you have had a chance to look my classes - I'm
> going to need to cope with varying algos in the very very near future so
> would like to take a crack at it.
>
> (If no one has had a chance, how do you all feel about me making a cvs
> branch?)
>
> Sean
>
> On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
>> Been thinking and I believe that the Enum way of going is a good idea
>> and so converted the util classes to them.
>>
>> So in CVS there is my proposal of how to do things. Let me know what
>> you think.
>>
>> Sean
>>
>>
>> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> > I guess we could change Algorithms from using straight Strings for
>> the constants to an Enum class style for type-safety.
>> >
>> > Something akin to:
>> >
>> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>> >
>> >
>> > Sean
>> >
>> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> > > Guys,
>> > >
>> > > I've committed to cvs 3 classes in jsdsi.util for handling of
>> algorythm names:
>> > >
>> > > Algorithms
>> > > DigestUtils
>> > > SignatureUtils
>> > >
>> > >
>> > >  - not implemented any of them yet as want input/comments first.
>> > >
>> > > The idea being that in Algorithms there is a list of constants
>> which clients use to indicate what they desire, e.g. DIGEST_MD5,
>> KEY_RSA, etc. There are then utility methods to calculate the SPKI
>> or JDK versions of such (This includes the problematic
>> Signatures).
>> > >
>> > > I would suggest the following coding ethos is JSDSI:
>> > >
>> > > 1. jsdsi object constructors that need algorythm names use SPKI
>> format names (this is what they should use now as that is the
>> format dumped to Sexpression, and consequently read from a stream)
>> > >
>> > > Not so sure about Hash.. has anyone looked at an Sexpression for
>> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be
>> sha1).
>> > >
>> > > Which then begs the question: should Hash.getAlgorithm() return
>> the SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> > >
>> > >
>> > >
>> > > 2. static create methods use the constants for easy client use.
>> > >
>> > > The question I have for this is about jsdsi.Signature. Should the
>> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> > >
>> > >
>> > >
>> > > Thoughts? (in particular problems this approach would lead to with
>> existing applications)
>> > >
>> > >
>> > > Sean
>> > >
>> > >
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net