Is DES not an option?

On Tue, 11 Mar 2003 18:12:22 -0600, [EMAIL PROTECTED] wrote:
>
>Language = Clarion 5.5EE, platform is Win98 and Win2000
>Server.
>
>My Blowfish code passes all the test vectors provided by
>the original creator of Blowfish, located here,
>
>http://www.counterpane.com/blowfish.html
>
>But as I stated, it was through the help of others who
>have successfully authored their own client code that I
>found out that the de-facto blowfish standard does not
>work with Tucows. In fact one person told me that they had
>CounterPane help them with getting the Blowfish alogorithm
>working and CounterPane told them the library you refer to
>is slightly different than the Blowfish spec. Thus without
>Tucows documenting this descrepency I'm SOL.
>
>
>We could easily digress into a spitting match about
>Blowfish and Tocows implementation, but my point is that
>the interface should not be so difficult to implement
>across different platforms as to allow such a spitting
>match to be a possibility .....
>
>
>Again, I am stating my request for platform independent
>support. Something as simple as enom's interface would be
>nice but not necessary. A free well documented Windows OS
>DLL would be more than adiquit and would support virtually
>all languages. Even better would be incremental test
>vectors for each Tucows API layer, but last time I asked
>for that it was suggested that I was a hacker attempting
>to reverse engineer other resellers private keys
>............ (sigh)
>
>
>Thanks!
>
>
>On Tue, 11 Mar 2003 08:35:12 -0500
>�Roger Ward <[EMAIL PROTECTED]>�wrote:
>>
>>Can you be more specific? You vent and yet don't say what
>>language you wrote
>>yours in.... if you've written it in C++/C/PHP/Perl, yet
>>need a blowfish
>>implementation... USE libmcrypt! It works!
>>
>>-Roger
>>
>>
>>
>>Quoting [EMAIL PROTECTED]:
>>
>>>
>>>�Fortunately many poeple came to my assistance in trying
>>>to
>>>�write my own interface ..... Then I was told that even
>>>�though my Blowfish algorithm satifies all the test
>>>vectors
>>>�it will not work for API since the Perl implementation
>>>�they use is slightly different than "the standard"
>>>......
>>>�I gave up at that point ....
>>>
>>>
>>>�So I guess I have to continue to use enom's nice API for
>>>�registration and then manually transfer to Tucows? Or is
>>>�Tucows going to simplify their API? Why can't Tucows
>>>make
>>>�my life so easy?
>>>
>>>
>>>�To be clear --
>>>
>>>�I really *DISLIKE* using enom and am in no why
>>>attempting
>>>�to promote them. But I am attempting to shame Tucows
>>>into
>>>�filling in the only hole I've found in their otherwise
>>>�stellar service: an API that is *REASONABLE* to
>>>implement
>>>�in the Resellers language of choice!
>>>
>>>
>>>�Thank you for this opertunity to vent. ;)
>>>
>>>
>>>�Joe Rhett <[EMAIL PROTECTED]>�wrote:
>>>�>Did you get any takers on this? �I wrote a C++ client
>>>�>back in late 2000,
>>>�>but it is far far out of date now.
>>>�>
>>>�>On Fri, Jan 24, 2003 at 01:33:25PM -0500, Frank
>>>Michlick
>>>�>wrote:
>>>�>>�Hi,
>>>�>>
>>>�>>�If anyone has implemented a client code to connect to
>>>�>>our API in C++,
>>>�>>�please email me ([EMAIL PROTECTED]), I'd be
>>>�>>interested in talking
>>>�>>�to you.
>>>�>>
>>>�>>�Thanks + best regards,
>>>�>>�Frank Michlick
>>>�>
>>>�>--
>>>�>Joe Rhett
>>>�>
>>>��������������������������Chief
>>>�>Geek
>>>�>[EMAIL PROTECTED]
>>>�>�������������������ISite Services,
>>>Inc.
>>>
>>>
>>


Reply via email to