> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-devel
