> However, the same file unconditionally uses SHA-1 in different places,
> so these #ifdef's doesn't work.
>
> All the ssh kex protocols that libssh2 supports require SHA-1, so it
> does not seem very useful to build libssh2 if there is no support for
> SHA-1 in OpenSSL. However, I may be missing something.
>
That..... is an excellent point.... and I agree, the SHA1 checks are
pointless when one considers the fact that all the current kex methods
require it. Might as well lose them.
Since you're doing all this shoehorn work to get libgcrypt working with
libssh2, I should mention that I've got some code I've been meaning to
toss in as a final-fallback (libbig_int for big number math, and my own
implementations of 3des-cbc (or aes256-cbc), sha1, and sha1-hmac for
minimal protocol support when neither library is available.
It's not that openssl or libgcrypt are so hard to come by, but I've been
asked for "stripped down" versions by people looking to do work with
embedded devices. If we can offer something that just does the bare
minimum, then that could be helpful to them.
libbig_int is licensed to the public domain so static linking that will
be simple, my sha1 and sha1-hmac implementations are already php
licensed (which is itself a bsd derivate), I just need to get some
permissions on using my 3des-cbc implementation from my employer (who
may have legal rights to it, not 100% clear...)
Note: I also have aes128/192/256-cbc implementations, but 3des-cbc is
the one specified as REQUIRED by the spec so it's the one I initially
mentioned. Given the relatively small size of the siphers, it might not
hurt the embedded folk to bad to include both families, or maybe give
them a ./configure time option.
One thing at a time though. I'm not quite out from under my work pile
to the point where I can start working on libssh2 yet, but I'm nearly there.
> If someone later on wishes to add support for, say, SHA-2, and make
> the SHA-1 stuff optional, that would be fine, but right now it doesn't
> seem to make sense to make SHA-1 optional since libssh2 won't work
> without SHA-1 (if I understand correctly).
>
I've got sha-256, sha-384, and sha-512 implementations as well, but
without an SSH standard which uses them they're not particularly helpful
right now...
What I do see is adding some of the other defined ciphers and modes
which libssh2 doesn't currently support because of lack of support in
OpenSSL. Particularly the -ctr cipher modes which allow the option to
safely remove the MAC blocks and cut down on the processing load a
little without sacrificing security.
-Sara
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
libssh2-devel mailing list
libssh2-devel_at_lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
Received on 2007-01-10