Now that I look at it, adding a new abstracted exchange_hash datatype into the various crypto libraries would be enough to resolve this issue, for now at least. We are looking at adding more exotic exchange types but would require much more extensive code churn.
That said, our team is working exclusively on openssl support. How do you deal with new features that aren’t being put back into libgcrypt for example?
Will
> On Jan 13, 2015, at 9:14 AM, Peter Stuge <peter_at_stuge.se> wrote:
>
> Will Cosgrove wrote:
>> Second, exhange_hash needs to change from libssh2_sha1_ctx to
>> something more generic.
> ..
>>>> First, kmdhgGPsha1kex_state_t is coded to be specific to sha1.
>
> So you are saying that libssh2 currently does not have hash
> abstraction, and you would like to add a new hash algo, correct?
>
> libssh2 *does* have crypto algo abstraction. Can you model a new
> hash algo abstraction after the existing crypto algo abstraction?
>
>
> //Peter
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2015-01-13