sorry i tried to attach, but it did not work. little over 19k encryped old
datagrams work to be decrypted, encrypted and compared.
the library (c#) has a wealth of algos and i am converting rc4 and shas since i
need them to go from modula-2 to d. maybe someone else sees the need to convert
some others ...
i use the cryptosys pki lib for the rest i don't have yet and try to attach the
d header.
funny i write that now for the second time, i hope it will end up in the ng
r

You might be interested in some existing crypto work I've done:
http://svn.dsource.org/projects/deimos/trunk/etc/crypto/hash/
The library "deimos" never really got off the ground, I think it may be
tome to salvage what can be salvaged from deimos and put it somewhere
else, perhaps in "Ares", Shaun? If the crypto stuff is unsuitable for any
reason let me know and I can re-work it.
Regan

Regan Heath wrote:
> You might be interested in some existing crypto work I've done:
> http://svn.dsource.org/projects/deimos/trunk/etc/crypto/hash/
>
> The library "deimos" never really got off the ground, I think it may be
> tome to salvage what can be salvaged from deimos and put it somewhere
> else, perhaps in "Ares", Shaun? If the crypto stuff is unsuitable for
> any reason let me know and I can re-work it.
>
> Regan
Woo Hoo! Definitely send the crypto stuff to Ares if Sean will have it. I
have a blowfish algorithm that I'm working on - not sure how it stacks up with
'r's version, but a consistent API for all of the crypto algorithms would be
great.
encryptString(char|wchar|dchar)
decryptString(char|wchar|dchar)
encryptFile()
decryptFile()
I'm not sure if this 'consistent' API is possible given the differences in the
crypto libs, or if it's a good idea at all.
BA

Regan Heath wrote:
> You might be interested in some existing crypto work I've done:
> http://svn.dsource.org/projects/deimos/trunk/etc/crypto/hash/
>
> The library "deimos" never really got off the ground, I think it may be
> tome to salvage what can be salvaged from deimos and put it somewhere
> else, perhaps in "Ares", Shaun? If the crypto stuff is unsuitable for
> any reason let me know and I can re-work it.
That's a bit past the level of what I've been focusing on, but it's
certainly a candidate for eventual inclusion.
Sean

On Thu, 23 Mar 2006 17:00:40 -0600, Brad Anderson wrote:
> Regan Heath wrote:
>> You might be interested in some existing crypto work I've done:
>> http://svn.dsource.org/projects/deimos/trunk/etc/crypto/hash/
>>
>> The library "deimos" never really got off the ground, I think it may be
>> tome to salvage what can be salvaged from deimos and put it somewhere
>> else, perhaps in "Ares", Shaun? If the crypto stuff is unsuitable for
>> any reason let me know and I can re-work it.
>>
>> Regan
>
> Woo Hoo! Definitely send the crypto stuff to Ares if Sean will have it. I
> have a blowfish algorithm that I'm working on - not sure how it stacks up with
> 'r's version, but a consistent API for all of the crypto algorithms would be
> great.
>
> encryptString(char|wchar|dchar)
> decryptString(char|wchar|dchar)
>
> encryptFile()
> decryptFile()
>
> I'm not sure if this 'consistent' API is possible given the differences in the
> crypto libs, or if it's a good idea at all.
Need to cater for non-text data too.
encryptData(ubyte[])
decryptData(ubyte[])
--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
24/03/2006 10:03:21 AM

Brad Anderson wrote:
> Regan Heath wrote:
>> You might be interested in some existing crypto work I've done:
>> http://svn.dsource.org/projects/deimos/trunk/etc/crypto/hash/
>>
>> The library "deimos" never really got off the ground, I think it may be
>> tome to salvage what can be salvaged from deimos and put it somewhere
>> else, perhaps in "Ares", Shaun? If the crypto stuff is unsuitable for
>> any reason let me know and I can re-work it.
>
> Woo Hoo! Definitely send the crypto stuff to Ares if Sean will have it. I
> have a blowfish algorithm that I'm working on - not sure how it stacks up with
> 'r's version, but a consistent API for all of the crypto algorithms would be
> great.
>
> encryptString(char|wchar|dchar)
> decryptString(char|wchar|dchar)
>
> encryptFile()
> decryptFile()
>
> I'm not sure if this 'consistent' API is possible given the differences in the
> crypto libs, or if it's a good idea at all.
I think it would be useful to have both standalone functions and filters
for IO. However, I think "standalone functions" may be a bit
misleading, as some attention should probably be paid to supporting
different encoding schemes and such with the same basic interface. I
don't have a tremendous amount of experience here, but I suppose the
.NET API might be one model to consider. The easiest thing in Ares
terms might be to consider this an add-on library, since crypto is
probably not so essential that it should be considered a core component.
So interface consistency would be an ultimate goal, but it wouldn't be
tied to the core library release schedule. This would also make it
easier to offer this as a standalone library for those who prefer
Phobos. Does this sound reasonable?
Sean