SHA-512 and long long - does SHA-512 depend on it?
Hello openssl-dev, Does SHA-512 depend on int64 support in the tool-chain? If so, are there any plans to make in a bit more portable? Thank you in advance. -- Best regards, Anthony mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
Does SHA-512 depend on int64 support in the tool-chain? Yes, it's explicitly mentioned in FAQ. If so, are there any plans to make in a bit more portable? Not really. As support for platforms narrower than 32-bit is discontinued, I'd rather recommend to disable algorithm in question with no-sha512 at configure stage or switch to more feature-rich compiler. How wide-spread the target platform? Is SHA512 really required in the context and/or does it really worth it? These are kind of question behind reasoning behind not really. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re[2]: SHA-512 and long long - does SHA-512 depend on it?
AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! As the more code in the OpenSSL gets updated - the more I'll disable in ./configure? Quite sad... AP How wide-spread the target platform? It is QNX4. Not as usual as windoze, but still very popular for robotics... AP Is SHA512 really required in the context and/or does it really AP worth it? To ensure the interoperability with modern clients on other platforms (SSH.com, OpenSSH) - yes. AP These are kind of question behind reasoning behind not AP really. :( -- Best regards, Anthony mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! Once again, platforms *narrower* than 32-bits are discontinued, in other words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) As the more code in the OpenSSL gets updated - the more I'll disable in ./configure? Quite sad... Life is not fair, never was, never will be:-) AP How wide-spread the target platform? It is QNX4. Not as usual as windoze, but still very popular for robotics... As far as I understand there is gcc for QNX, so why not use it as more feature-rich compiler? AP Is SHA512 really required in the context and/or does it really AP worth it? To ensure the interoperability with modern clients on other platforms (SSH.com, OpenSSH) - yes. Is there evidence that there will be applications emerging that will refuse to negotiate anything else but SHA-512? I find it hard to believe. I reckon that disabling SHA-512 does not impose risk of reduced interoperability in the time-frame of release-span of any particular platform/compiler. Meanwhile ask your vendor to implement long long support:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
On Friday 15 July 2005 13:32, Andy Polyakov wrote: AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! Once again, platforms *narrower* than 32-bits are discontinued, in other words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) What's so hard to believe about a 16 bit embedded system (or even an 8 bit embedded system) that may need some kind of secure network access? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! Once again, platforms *narrower* than 32-bits are discontinued, in other words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) What's so hard to believe about a 16 bit embedded system (or even an 8 bit embedded system) that may need some kind of secure network access? I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
On Fri, 15 Jul 2005, Andy Polyakov wrote: I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. Lots of embedded work is still on 8-bit processors- 8051s, 68HC11s, etc. The 16 bits are being replaced by low-end 32-bit processors. But 8-bits are going to be here for a long time. I'm not sure that OpenSSL is a good code base to be used on 8-bit embedded systems, and at 200K, it's probably iffy for 16-bit systems. So I could easily see OpenSSL going We don't support small systems (sub 32-bit). But that doesn't mean they aren't out there. Brian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
Actually, my point about embedded systems wasn't that they'd necessarily have the full suite of OpenSSL, but that a pared-down version would be desirable. If all I want to do is triple DES with anonymous DH for key exchange on an embedded platform (for example), OpenSSL is probably a good place to start. By explicitly abandoning sub-32 bit systems, this may not be an option going forward. On Friday 15 July 2005 14:05, Brian Hurt wrote: On Fri, 15 Jul 2005, Andy Polyakov wrote: I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. Lots of embedded work is still on 8-bit processors- 8051s, 68HC11s, etc. The 16 bits are being replaced by low-end 32-bit processors. But 8-bits are going to be here for a long time. I'm not sure that OpenSSL is a good code base to be used on 8-bit embedded systems, and at 200K, it's probably iffy for 16-bit systems. So I could easily see OpenSSL going We don't support small systems (sub 32-bit). But that doesn't mean they aren't out there. Brian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re[2]: SHA-512 and long long - does SHA-512 depend on it?
Hello Andy, Friday, July 15, 2005, 9:32:10 PM, you wrote: AP Once again, platforms *narrower* than 32-bits are discontinued, in other AP words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) Oh! Yes, now I see the point - *NARROWER*! QNX4 is 32bit OS. The only problem is in the tool-chain (Watcom C v10.6B does not support int64)... AP As far as I understand there is gcc for QNX, so why not use it as more AP feature-rich compiler? I'm afraid it becomes an off-topic here... gcc v2.8 or something, roumors are it is quite buggy... And stale... :( AP Meanwhile ask your vendor to implement long long support :-) :) Indeed! :)) :( OK. Thank you! -- Best regards, Anthonymailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
On Fri, 15 Jul 2005, Jim Schneider wrote: Actually, my point about embedded systems wasn't that they'd necessarily have the full suite of OpenSSL, but that a pared-down version would be desirable. If all I want to do is triple DES with anonymous DH for key exchange on an embedded platform (for example), OpenSSL is probably a good place to start. By explicitly abandoning sub-32 bit systems, this may not be an option going forward. The 8-bit system I have experience on (Cypress EZ-USB 8051) had like 8K of ROM, and 256 bytes- not kilobytes, not megabytes, *bytes*- of RAM. Now, you can implement triple-des and DH in this space, but it basically requires a dedicated implementations. You can't afford to waste a byte. The gray area is 16-bit systems, with hundreds of K to say a meg of memory. The problem is that there is increasingly less cost difference between the 16-bit CPUs and the low end 32-bit ARM and PPC cpus. Which means the 16-bit market is going away, from what I've seen. Brian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
What's so hard to believe about a 16 bit embedded system (or even an 8 bit embedded system) that may need some kind of secure network access? Nothing at all. What's hard to imagine is that a free development effort must support all the latest and greatest crypto techniques for such a platform. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
