RE: [openssl.org #2162] Updated CMAC, CCM, GCM code

Due to the complete missing of an optimization in the IBM proposal I am currently working on a GCM version as well. My current work includes: - EVP support for the CTR128 modes *1) (AES and Camellia), as these are required in the GCTR [SP800-38D] function of the GCM (instead of a block-wise

Re: [openssl.org #2162] Updated CMAC, CCM, GCM code

On Wed, Mar 03, 2010, PMHager wrote: - EVP support for the CTR128 modes *1) (AES and Camellia), as these are required in the GCTR [SP800-38D] function of the GCM (instead of a block-wise use of the ECB mode), Andy has added EVP support for CTR128 already. - redesign of the EVP

Re: [openssl.org #2162] Updated CMAC, CCM, GCM code

Hi, Due to the complete missing of an optimization in the IBM proposal I am currently working on a GCM version as well. My current work includes: - EVP support for the CTR128 modes *1) (AES and Camellia), AES counter was recently added, see http://cvs.openssl.org/chngview?cn=19314.

RE: [openssl.org #2162] Updated CMAC, CCM, GCM code

- EVP support for the CTR128 modes *1) (AES and Camellia), as these are required in the GCTR [SP800-38D] function of the GCM (instead of a block-wise use of the ECB mode), Andy has added EVP support for CTR128 already. Unfortunately, I do not have access to the CVS. So, as I had needed

Re: [openssl.org #2162] Updated CMAC, CCM, GCM code

On Wed, Mar 03, 2010, PMHager wrote: I don't see why the existing EVP_CIPHER interface isn't suitable. You add a new flag for GCM/CCM mode and pass or retrieve additional information via standardized ctrls. The difficulties I see are the restricted parameters at EVP_CipherInit_ex(),

Re: [openssl.org #2162] Updated CMAC, CCM, GCM code

On Wed, Mar 03, 2010 at 02:56:07PM +0100, Dr. Stephen Henson wrote: I'm thinking here that we should have a standardised technique for handling encrypt+mac which will also cover possible future needs. As far as I can tell, there isn't even working support for plain old MAC in the engine

Re: [openssl.org #2162] Updated CMAC, CCM, GCM code

In case you consider submitting assembler code there is couple of requirements that has to be met. Inline assembler (or exotic intrinsics) is not considered as viable option for MMX/SSE (or any code bigger than couple of instructions), perlasm code is. As it is available in the MSC,

NO_FORK problem in speed.c

Hi All, I have build the new openssl-0.9.8m on HPUX platform, it sees that the openssl-0.9.8m don't support the command line openssl speed -multi 2. And I have traced to the source code of speed.c. But it work fines with the openssl-0.9.8l. The reason is that : #if defined(OPENSSL_SYS_VMS)

Re: NO_FORK problem in speed.c

On Wed, 3 Mar 2010, kai_yang2008 wrote: Hi All, I have build the new openssl-0.9.8m on HPUX platform, it sees that the openssl-0.9.8m don't support the command line openssl speed -multi 2. And I have traced to the source code of speed.c. But it work fines with the openssl-0.9.8l. The reason

[openssl.org #2183] 0.9.8m broke -multi option in openssl(1) on unix(-like) systems

commit 18494 changed how HAVE_FORK is dealt with in speed.c. The original submitter (http://www.mail-archive.com/openssl-dev@openssl.org/msg26278.html) correctly stated that HAVE_FORK should be defined by the configure script but wrongly assumed that it really was. it's not

[openssl.org #2183] 0.9.8m broke -multi option in openssl(1) on unix(-like) systems

[jan.pecha...@sun.com - Wed Mar 03 19:27:30 2010]: commit 18494 changed how HAVE_FORK is dealt with in speed.c. The original submitter (http://www.mail-archive.com/openssl-dev@openssl.org/msg26278.html) correctly stated that HAVE_FORK should be defined by the configure script

[openssl.org #2184] patch for openssl-0.9.8m on haiku

Here's the patch I used for building openssl-0.9.8m for Haiku: http://ports.haiku-files.org/export/620/haikuports/trunk/dev-libs/openssl/patches/openssl-0.9.8m.patch -scottmc Scott McCreary HaikuPorts (http://ports.haiku-files.org)