[openssl.org #1800] openssl verification should read algorithm from signature
Hello! When verifying a signature using openssl dgst, openssl does not read the hash algorithm from the signature: $ openssl dgst -sha1 -verify public.pem -signature content.signature content Verified OK $ openssl dgst -verify public.pem -signature content.signature content Verification Failure I would like to write a patch to read the hash algorithm from the signature. But only if someone is interested in merging the patch. I wont make the effort to let it bitrot in a tracker... Cheers, Kosta __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1800] openssl verification should read algorithm from signature
[ko...@fillibach.de - Sun Dec 14 13:21:24 2008]: I would like to write a patch to read the hash algorithm from the signature. But only if someone is interested in merging the patch. I wont make the effort to let it bitrot in a tracker... This would only work with RSA PKCS#1 v1.5 signatures. Other schemes do not include the hash algorithm in the signature. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Realligning const void *data variables into 32-bit boundaries
On Sat, Dec 13, 2008 at 7:26 PM, Vishnu Param vishnu...@hotmail.com wrote: Which is faster (memcpy or inline or and operations)? It varies widely [...] But i guess this only applies for my hardware and not others. It is really hard to say what the compiler is doing beneath the system, and I am no expert in these matters. Correct. Though as a rule of thumb, one can assume memcpy()/memcmp()/memmove() to be faster than 'home grown' versions of the same. BTW: if you ever want or need to know what's done under the hood, check out disassemblers (such as IDA Pro). Powerful stuff. And many compilers (e.g. Intel ICC, GNU C) recognize several (mem*/str*) standard lib calls and replace them with 'intrinsics', i.e. highly optimized bits of inline assembly. memcpy() is one such a call. It depends very much on the compiler, the (hardware) platform and the compiler settings. Other compilers provide optimized memcpy() library calls which are a tad slower, thanks to the function call/return overhead, but they very probably still outperform 'home grown'. All in all, the most important thing is to feed (relatively) large chunks of data on each call, so call overhead and such is 'negligable', compared to the data processing itself. And when you can devise your software in such a way that data, which must be aligned, enters the system at an aligned boundary already, that cuts out the aligning memcpy/memmove and gives some additional speed. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH RFC] Add support to Intel AES-NI instruction set for x86_64 platform
On Fri, 2008-12-12 at 12:24 +0800, Geoff Thorpe wrote: On Thursday 11 December 2008 23:02:12 Huang Ying wrote: On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote: The cipher and digest support is at the granularity of nids, and these combine algorithm, key-length, and mode. So if you implement support for those cipher,length,mode combinations that can be accelerated by AES-NI, your engine will only be invoked for those combinations. You're not obliged to implement anything else, and indeed there is nothing to be gained by doing so. The situation is: - We implement cbc and ecb mode in engine - If we implement cfb and ofb in engine too, we will duplicate code of cfb and ofb mode itself. - If we do not implement cfb and ofb in engine, no code duplication, BUT we can NOT get AES-NI acceleration for AES core block algorithm (which benefit cfb and ofb too) until we have a branch version. OK, I (mis)understood from your original mail that you could only accelerate a subset of modes. If you can accelerate them all, then please do so by implementing an intel/aes-ni engine. But not by branching in the vanilla implementation. So my suggestion is: - Accelerate AES core block algorithm with branch version. Which is used by cbc, cfb and ofb too. - Accelerate AES ecb and ctr? with engine version. And my suggestion is: - write an engine for your hardware. OK. I will write an engine version firstly, at least for discussion. Best Regards, Huang Ying signature.asc Description: This is a digitally signed message part
