Does OpenSSL 0.9.7d supports ISo-8859-15 character set?
HI, Does OpenSSL 0.9.7d supports ISO-8859-15 character set ? Is there any flag that needs to set for supporting this charset ? Please do reply. With Regards Bhalchandra Deshmukh
Re: Elliptic curves + openssl
Hi! How can I use elliptic curve algorithm from opnessl with OPNET simulator??? Thanks in advance chrystelle wrote: Hi! I would like to know how can I use the elliptic curves's algorithms with openssl? Thanks -- View this message in context: http://www.nabble.com/Elliptic-curves-%2B-openssl-tp17910727p21016981.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
speaking of padlock engine
Does anybody have VIA Nano-based system? VIA Nano is the one implementing x86_64. Naturally system running 64-bit OS? A. __ 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
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. The plan is to consolidate mode implementations, so it doesn't have to be the case [anymore], see http://cvs.openssl.org/chngview?cn=17692. - 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. Just to clarify CBC situation. While it's absolutely correct that *de*cryption is the one that can take full advantage of pipe-lining, dedicated *en*cryption procedure should also be implemented in assembler. Why? It doesn't come as surprise that CBC timing is sum of time spent in block procedure and time spent performing the block chaining. The latter can be underestimated and as block procedure gets faster it actually becomes underestimated. I reckon that with 4x faster block procedure, C timing for block chaining would be comparable with block procedure. This in turn means that overall performance would be almost twice as low as if chaining was implemented in assembler. This applies to x86_64, on x86 performance loss would be even higher... 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. I second it. And additional note. As padlock engine was mentioned, I can imagine that the idea of using inline assembler will pop up in the head. Please don't! As already mentioned we support other compilers as well and it's favorable if gcc-ims can be avoided. Well, in 32-bit case it might be acceptable (both GNU and Microsoft compilers support inline assembler), but not in 64-bit case (GNU is the only one supporting inline assembler). As for FIPS. Given current precedent it should be noted that if branch version is certified, then the branch becomes bound to be taken. In other words branched version would be prohibited to reach certified mode of operation on CPU that does not support the instruction set extension in question. Then why does it have to be branched? Having this in mind wouldn't it make as much sense to implement module that can be used as *drop-in replacement* for aes-[586|x86_64].pl? So that those who are willing to pursue certification for given hardware can do so with not so much hassle(*)? Would it be effort duplication? Does not have to be! Because the code can be used in engine context just as well... Now to practicalities. What I can do to help. I can put together perl scripts for x86_64 and x86, which can be used as drop-in replacement for aes-[586|x86_64].pl as well as in engine context. Note that drop-in replacement implies presence of CBC procedure, though I'd be reluctant to implement pipe-lined version. At least not without further consideration, because it might turn out that pipe-lined version doesn't have to monolithic. Most notably one can break decryption into multi-block ECB and separate multi-block chaining to minimize developing effort. A. (*) such narrow platform binding is hardly of general interest till given instruction set implementation is really common place (and hopefully multi-vendor:-). __ 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
Implementation aiming to complement interface exposed by crypto/aes/asm should allow for non-16-byte-aligned key schedule. Period. One can use movups, or check alignment and choose between movups and movaps code paths, or copy key schedule to aligned location on stack. Should it be considered an unsafe behavior to copy key schedule to stack? The stack maybe swapped out to a swap file, so that the key schedule is leaked. Not that I'm answering the question with a question, but what's wrong with movups? I mean I consider that the question about copying key schedule was already discussed in enough detail, but I'm left with feeling that other options are even less preferable. So I wonder why? Is movups expected to so much worse? Even if input is moderately misaligned, say at 64-bit boundary instead of 128? Can't one pipe-line it, i.e. schedule movups longer before aes[enc|dec], to amortize' additional latency, or will it be non-pipe-line-able? Even if so, it's possible to compromise having movaps and palignr. If one chooses to declare key schedule to ensure 64-bit alignment(*) it would really have to be a single palignr case... A. (*) for example see http://cvs.openssl.org/fileview?f=openssl/crypto/camellia/camellia.hv=1.4. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [CVS] OpenSSL: openssl/crypto/ crypto-lib.com install.com openssl/engi...
On Tuesday 16 December 2008 05:54:28 Richard Levitte wrote: OpenSSL CVS Repository http://cvs.openssl.org/ __ __ Server: cvs.openssl.org Name: Richard Levitte He's bck! :-) How's things? Merry christmas, happy new year, and all that. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [CVS] OpenSSL: openssl/crypto/ crypto-lib.com install.com openssl/engi...
Oops, chalk up another victim to reply-to ... sorry for the noise (and the follow-up noise of this apology). Cheers, Geoff On Tuesday 16 December 2008 14:52:34 Geoff Thorpe wrote: On Tuesday 16 December 2008 05:54:28 Richard Levitte wrote: OpenSSL CVS Repository http://cvs.openssl.org/ __ __ Server: cvs.openssl.org Name: Richard Levitte He's bck! :-) How's things? Merry christmas, happy new year, and all that. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ 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
From: owner-openssl-...@openssl.org On Behalf Of Ger Hobbelt Sent: Sunday, 14 December, 2008 14:18 snip some What I was trying to attain was a 'correction offset', derived from the originally unaligned pointer, and add that to the pointer (while having it cast as a byte* pointer so offsets would be counted as bytes). In your code the offset is (good - (uint)rawptr). If pointers don't (or might not) fit in (u)integers, yes. If they do fit in e.g. ulong, I just use that directly. I used a (slower) modulo operator, so the signed/unsigned type of the final offset result isn't important as only the lowest bits will end up in there due to unsigned intermediates. For power-of-2 wordsize the modulo wordsize === bitwise-and (wordsize-1) The intermediate is only unsigned if you make it so. C defines % for both signed and unsigned, but signed is likely (C89) or certain (C99) to give the wrong result for values in (cast to) the negative 'half' of signed as you first had. (Pascal, if I remember, defines MOD and REM differently for negative, and you can get what you need here. Not C.) Modulo power-of-2 (of unsigned or nonnegative) is bitand, yes. In fact if a compiler sees that, it will usually do the optimization for you. But this function has wordsize passed as an argument so the compiler can't see it, unless you get it to be inlined -- which at minimum means copied/#include'd into each client module. (For some compilers you also need C99 'inline', or a pragma, or such.) Another way is to make the argument be log2_wordsize i.e. the number of bits of alignment, then do %(1Unbit) ; that is arguably clearer. Alternatively a code macro is always inlined, and defensible for a simple thing like this (1 maybe 2 codelines really needed). void* rawptr = malloc_or_whatever; if (wordsize = 0) goto err; /* uint offset = (((uint)wordsize) - ((uint)rawptr)) % wordsize; or for power-of-2 wordsizes only: */ uint offset = (((uint)wordsize) - ((uint)rawptr)) (wordsize - 1); uchar* al_ptr = ((uchar*)rawptr) + offset; For non-power-of-2 that % version wouldn't work right either. If you ALSO keep the one you had before: offset = ( wordsize - (utype)rawptr % wordsize ) % wordsize it will, IF utype is big enough to hold pointer values. If there isn't a big enough u-integer, you can't just take the low bits as you can for power-of-2, you have to do 'multiprecision' integer or more complicated tricks to correct for the residues. Real machines ARE power-of-2 so I don't think it's worth it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [CVS] OpenSSL: openssl/crypto/ crypto-lib.com install.com openssl/engi...
In message 200812161452.34284.ge...@geoffthorpe.net on Tue, 16 Dec 2008 14:52:34 -0500, Geoff Thorpe ge...@geoffthorpe.net said: geoff On Tuesday 16 December 2008 05:54:28 Richard Levitte wrote: geoffOpenSSL CVS Repository geoffhttp://cvs.openssl.org/ geoff geoff __ geoff __ geoff geoffServer: cvs.openssl.org Name: Richard Levitte geoff geoff He's bck! :-) *laugh* *bow* geoff How's things? Merry christmas, happy new year, and all that. Things are damn good. Life is changing, quite a few new things to discover in myself, there are some new things I've had to adapt to, but it's all worth it :-). Currently in the midst of having one gf moving in with me, and preparing for 3 kittens to move in as well (they're coming this weekend). Merry holydays (whichever y'all celebrate), happy new year, yeah all that ;-) Cheers, Richard ( has taken a look at what's happening in OpenSSL and got a couple of happy surprises :-) ) -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ 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 Tue, 2008-12-16 at 21:30 +0800, Andy Polyakov wrote: Implementation aiming to complement interface exposed by crypto/aes/asm should allow for non-16-byte-aligned key schedule. Period. One can use movups, or check alignment and choose between movups and movaps code paths, or copy key schedule to aligned location on stack. Should it be considered an unsafe behavior to copy key schedule to stack? The stack maybe swapped out to a swap file, so that the key schedule is leaked. Not that I'm answering the question with a question, but what's wrong with movups? I mean I consider that the question about copying key schedule was already discussed in enough detail, but I'm left with feeling that other options are even less preferable. So I wonder why? Is movups expected to so much worse? Even if input is moderately misaligned, say at 64-bit boundary instead of 128? Can't one pipe-line it, i.e. schedule movups longer before aes[enc|dec], to amortize' additional latency, or will it be non-pipe-line-able? Even if so, it's possible to compromise having movaps and palignr. If one chooses to declare key schedule to ensure 64-bit alignment(*) it would really have to be a single palignr case... A. That sounds interesting. At least deserve try. Best Regards, Huang Ying signature.asc Description: This is a digitally signed message part
Re: [PATCH RFC] Add support to Intel AES-NI instruction set for x86_64 platform
On Tue, 2008-12-16 at 19:12 +0800, Andy Polyakov 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. The plan is to consolidate mode implementations, so it doesn't have to be the case [anymore], see http://cvs.openssl.org/chngview?cn=17692. Good! Hope that can be merged quickly. - 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. Just to clarify CBC situation. While it's absolutely correct that *de*cryption is the one that can take full advantage of pipe-lining, dedicated *en*cryption procedure should also be implemented in assembler. Why? It doesn't come as surprise that CBC timing is sum of time spent in block procedure and time spent performing the block chaining. The latter can be underestimated and as block procedure gets faster it actually becomes underestimated. I reckon that with 4x faster block procedure, C timing for block chaining would be comparable with block procedure. This in turn means that overall performance would be almost twice as low as if chaining was implemented in assembler. This applies to x86_64, on x86 performance loss would be even higher... OK, I will implement CBC encryption with ASM too. 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. I second it. And additional note. As padlock engine was mentioned, I can imagine that the idea of using inline assembler will pop up in the head. Please don't! As already mentioned we support other compilers as well and it's favorable if gcc-ims can be avoided. Well, in 32-bit case it might be acceptable (both GNU and Microsoft compilers support inline assembler), but not in 64-bit case (GNU is the only one supporting inline assembler). OK. I will use same format as aes-x86_64.pl. As for FIPS. Given current precedent it should be noted that if branch version is certified, then the branch becomes bound to be taken. In other words branched version would be prohibited to reach certified mode of operation on CPU that does not support the instruction set extension in question. Then why does it have to be branched? Having this in mind wouldn't it make as much sense to implement module that can be used as *drop-in replacement* for aes-[586|x86_64].pl? So that those who are willing to pursue certification for given hardware can do so with not so much hassle(*)? Would it be effort duplication? Does not have to be! Because the code can be used in engine context just as well... Now to practicalities. What I can do to help. I can put together perl scripts for x86_64 and x86, which can be used as drop-in replacement for aes-[586|x86_64].pl as well as in engine context. Note that drop-in replacement implies presence of CBC procedure, though I'd be reluctant to implement pipe-lined version. At least not without further consideration, because it might turn out that pipe-lined version doesn't have to monolithic. Most notably one can break decryption into multi-block ECB and separate multi-block chaining to minimize developing effort. A. Thank you very much. I can change the format to perl format, but need your help to test it on Windows 64 and fix some issue such as SSE operands. I think AES-NI based pipelined implementation can be a start point for general version. Best Regards, Huang Ying signature.asc Description: This is a digitally signed message part
