Patch: save/load state of SHA1
Hello,
We need to calculate SHA1 over a large sequence of messages. Related
messages can arrive with huge intervals (hours, days worst case),
including across program shutdown, and we can not keep old messages
around to do the SHA1 all at once.
Our situation requires the ability to save the state of a SHA1
calculation in progress to a file or database, and reload it later to
contiue with it.
Attached to this email is a patch against 0.9.8e that adds this ability
to OpenSSL.
cd openssl-0.9.8.e/crypto
patch -p0 openssl-sha-save-v1.patch
Use example:
SHA1_Init();
SHA1_Update();
SHA1_Save_State(VERSION_DONT_CARE);
SHA1_Drop();// Application must call this if it doesn't do
SHA1_Final on a context
...
anything, including program shutdown
...
SHA1_Load_State();
SHA1_Update();
SHA1_Final();
We think that some other users may encounter a situation similar to
ours, and we therefore submit this patch for inclusion.
If the patch is not rejected outright, I am willing to modify the patch
to make it eligible for inclusion. E.g. add the documentation, any
cleanups, etc.
Regards,
Nanno
diff -Nru ../../openssl-0.9.8e/crypto/sha/sha.h sha/sha.h
--- ../../openssl-0.9.8e/crypto/sha/sha.h 2006-12-22 17:04:56.0 +0100
+++ sha/sha.h 2007-06-08 01:47:07.203240896 +0200
@@ -97,6 +97,9 @@
#define SHA_LAST_BLOCK (SHA_CBLOCK-8)
#define SHA_DIGEST_LENGTH 20
+#define SHA_STATE_VERSION_DONT_CARE 0
+#define SHA_STATE_VERSION_1 1
+
typedef struct SHAstate_st
{
SHA_LONG h0,h1,h2,h3,h4;
@@ -118,6 +121,9 @@
int SHA1_Final(unsigned char *md, SHA_CTX *c);
unsigned char *SHA1(const unsigned char *d, size_t n, unsigned char *md);
void SHA1_Transform(SHA_CTX *c, const unsigned char *data);
+void SHA1_Save_State(SHA_CTX *c, unsigned char **data, unsigned int *len, int requested_version);
+int SHA1_Load_State(SHA_CTX *c, unsigned char *data, unsigned int len);
+void SHA1_Drop(SHA_CTX *c);
#endif
#define SHA256_CBLOCK (SHA_LBLOCK*4) /* SHA-256 treats input data as a
diff -Nru ../../openssl-0.9.8e/crypto/sha/sha_locl.h sha/sha_locl.h
--- ../../openssl-0.9.8e/crypto/sha/sha_locl.h 2005-07-20 01:10:04.0 +0200
+++ sha/sha_locl.h 2007-06-08 02:36:44.043692360 +0200
@@ -58,6 +58,8 @@
#include stdlib.h
#include string.h
+#include stdint.h // For uint32_t
+#include netinet/in.h // For htonl/ntohl
#include openssl/opensslconf.h
#include openssl/sha.h
@@ -603,3 +605,93 @@
#endif
#endif
+
+
+#if defined(SHA_1)
+#define memcat_htobe32(dst, src) { *(uint32_t*)(dst) = htonl(src); (dst) += sizeof(uint32_t); }
+#define memget_betoh32(dst, src) { (dst) = ntohl( *((uint32_t*)(src)) ); (src) += sizeof(uint32_t); }
+
+#define SHA_STATE_V1_SIZE ((1 + 5 + 2 + SHA_LBLOCK + 1) * sizeof(uint32_t))
+
+void SHA1_Save_State (SHA_CTX *c, unsigned char **data, unsigned int *len, int requested_version)
+ {
+ unsigned char *p;
+ int i;
+
+ switch (requested_version)
+ {
+ case SHA_STATE_VERSION_DONT_CARE:
+ requested_version = SHA_STATE_VERSION_1;
+ break;
+ case SHA_STATE_VERSION_1:
+ break;
+ default:
+ *data = NULL;
+ return;
+ }
+
+ *len = SHA_STATE_V1_SIZE;
+ *data = malloc(*len);
+ if (*data == NULL) {
+ return;
+ }
+
+ p = *data;
+
+ memcat_htobe32(p, requested_version);
+
+ memcat_htobe32(p, c-h0);
+ memcat_htobe32(p, c-h1);
+ memcat_htobe32(p, c-h2);
+ memcat_htobe32(p, c-h3);
+ memcat_htobe32(p, c-h4);
+
+ memcat_htobe32(p, c-Nl);
+ memcat_htobe32(p, c-Nh);
+
+ for (i=0; iSHA_LBLOCK; i++)
+ {
+ memcat_htobe32(p, c-data[i]);
+ }
+
+ memcat_htobe32(p, c-num);
+ }
+
+int SHA1_Load_State (SHA_CTX *c, unsigned char *data, unsigned int len)
+ {
+ int version, i;
+
+ if (len sizeof(uint32_t))
+ return -1;
+
+ memget_betoh32(version, data);
+ if (version != SHA_STATE_VERSION_1)
+ return -2;
+ if (len SHA_STATE_V1_SIZE)
+ return -3;
+
+ memget_betoh32(c-h0, data);
+ memget_betoh32(c-h1, data);
+ memget_betoh32(c-h2, data);
+ memget_betoh32(c-h3, data);
+ memget_betoh32(c-h4, data);
+
+ memget_betoh32(c-Nl, data);
+ memget_betoh32(c-Nh, data);
+
+ for (i=0; iSHA_LBLOCK; i++)
+ {
+ memget_betoh32(c-data[i], data);
+ }
+
+ memget_betoh32(c-num, data);
+
+ return 1;
+ }
+
+void SHA1_Drop (SHA_CTX *c)
+ {
+ // There is no dynamically allocated memory to clean up.
+ }
+#endif
+
#include stdio.h
#include stdbool.h
#include stdint.h
#include openssl/sha.h
int main()
{
SHA_CTX a, b;
uint8_t digest_a[SHA_DIGEST_LENGTH], digest_b[SHA_DIGEST_LENGTH];
uint8_t data[67];
bool equal;
unsigned char *state;
unsigned int state_len;
int i, cut, ret;
equal = true;
for (i=0; isizeof(data); i++)
data[i] = i;
for (cut=0; cutsizeof(data); cut++) {
SHA1_Init(a);
memset(b, 0, sizeof(b));
for (i=0; isizeof(data); i++) {
if (i == cut) {
SHA1_Save_State(a, state, state_len, SHA_STATE_VERSION_DONT_CARE);
if (state == NULL) {
printf(Error!\n);
return 1;
}
ret = SHA1_Load_State(b, state, state_len);
if (ret != 1) {
Regarding extended key usage extension implementation which differs from RFC 2459
Hi, This question is regarding the extended key usage extension implementation which differs from the specification [RFC 2459]. I read RFC 2459 in http://www.faqs.org/rfcs/rfc2459.html section 4.2.1.13 Extended key usage field. It says that If the extension is flagged non-critical, then it indicates the intended purpose or purposes of the key, and may be used in finding the correct key/certificate of an entity that has multiple keys/certificates. It is an advisory field and does not imply that usage of the key is restricted by the certification authority to the purpose indicated. Certificate using applications may nevertheless require that a particular purpose be indicated in order for the certificate to be acceptable to that application. But in http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS, it says that openssl uses the key only for the specified purpose, if the extended key usage is present regardless of whether it is critical or not. So, my question is why is openssl acting as if extended key usage is critical even though it is marked as non-critical? Thanks Durga Prasad - Durga Prasad Jammula webpage : http://durgaprasad.wordpress.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Linux version of Attribute certificate API
Hello, I have compiled the Attribute Certificate API on Linux and it is working with OpenSSL 0.9.8a (I didn't check other versions) The source can be downloaded at http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml There are 3 versions: Version 0.1 (Windows only) Version 0.1 (Linux/Windows) some minor changes to the Windows version (types and casts). It should work in windows also. Version 0.2 (Windows) Includes some bugfixes and new functions to assist the issuing process. Those new functions can be personalized using callbacks. New functions are not yet covered by documentation. I will try to move version 0.2 to Linux and also to finish the verifier for version 0.3 (if I have some spare time) Regards, Daniel -- Daniel Diaz Sanchez Telecommunication Engineer Researcher / Teaching Assistant Dep. Ing. Telemática Universidad Carlos III de Madrid Av. Universidad, 30 28911 Leganés (Madrid/Spain) Tel: (+34) 91-624-6233, Fax: -8749 Web: www.it.uc3m.es/dds web: http://www.it.uc3m.es/pervasive A toolkit for attribute certificates: http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml Mail: dds[at].it.uc3m.es Skype: dds.it.uc3m.es __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
AES+OpenSsl+ubsec hardware accelerator
I'm using an BCM5823 SSL accelerator card and RSA/DSA work great, However I can't get the cipher support going for AES etc. I saw this reference on the mailing list: http://www.mail-archive.com/openssl-dev@openssl.org/msg19046.html Looks like someone got it working, but can't find it anywhere in the source or how to enable it. Has anyone got this to work? Thanks!! Trevor Paskett - CCNA, CWNA Cymphonix Director of Engineering P: 801-938-1500 F: 801-938-1501
RE: Linux version of Attribute certificate API
The library works also with last openSSL version. I send also a complete trace of the execution with the last openSSL version on linux. Regards, Pervasive Computing Laboratory - - -- This program is a test tool for attribute certificate wrapper Create attribute certificate Setting version to v2 Setting holder and issuer Setting time validity Setting the attributes Printing the attribute certificate -- AC Version= v2, Issuer Information -- -name(GNs):DirName: /C=ES/ST=Madrid/L=Leganes/O=Universidad Carlos III/CN=SoA/[EMAIL PROTECTED] -serial(INT):e3:1e:d2:8b:a0:60:53:2f: -issuerUniqueID(INT):NULL Holder Information -- Holder BaseCertID: -name(GNs):DirName: /C=es/ST=Madrid/L=Leganes/O=Universidad Carlos III/CN=User/[EMAIL PROTECTED] -serial(INT):bd:a6:37:3d:db:9e:37:89: -issuerUniqueID(INT):NULL Validity Valid not before: 20070608185543Z Valid not after: 20070615185543Z Attribute information - Number of attributes: 4 Attribute Number: 0 Attribute NID: 354 , Name: id-aca-authenticationInfo Service Authentication Information Attribute syntax SvceAuthInfo Consumed by the target application not the AC verifier Multiple values allowed : yes Values: 2 Printing value: 0 -- Ident information : Present DirName: /C=es/ST=Madrid/L=Leganes/O=Universidad Carlos III/CN=User/[EMAIL PROTECTED] Service information : Present DirName: /C=ES/ST=Madrid/L=Leganes/O=Universidad Carlos III de Madrid/OU=Departamento Ingenieria Telematica/CN=Servicio de correo electronico Auth Info : Not present Printing value: 1 -- Ident information : Present DirName: /C=es/ST=Madrid/L=Leganes/O=Universidad Carlos III/CN=User/[EMAIL PROTECTED] Service information : Present DirName: /C=ES/ST=Madrid/L=Getafe/O=Universidad Carlos III de Madrid/OU=Library/CN=Catalog Auth Info : Not present Attribute Number: 1 Attribute NID: 355 , Name: id-aca-accessIdentity Access Identity Attribute syntax SvceAuthInfo without AuthInfo Consumed by the AC verifier to authorise Multiple values allowed : yes Values: 1 Printing value: 0 -- Ident information : Present DirName: /C=es/ST=Madrid/L=Leganes/O=Universidad Carlos III/CN=User/[EMAIL PROTECTED] Service information : Present DirName: /C=ES/ST=Madrid/L=Leganes/O=Universidad Carlos III de Madrid/OU=Departamento Ingenieria Telematica/CN=Servicio de correo electronico Auth Info : Not present... it should be not present! Attribute Number: 2 Attribute NID: 356 , Name: id-aca-chargingIdentity Charging Identity Attribute syntax IetfAttrSyntax Consumed by the AC verifier to authorise Multiple values allowed : no Values: 1 Printing value: 0 -- Policy Authority information : Present DirName: /C=es/ST=Madrid/L=Leganes/O=Universidad Carlos III/CN=User/[EMAIL PROTECTED] Type of info : V_ASN1_OCTET_STRING 0x530x6f0x6d0x650x200x640x610x740x610x200x740x6f0x200x610x640x640x200x740x6f 0x2e0x2e0x2e0x2e0x2e Attribute Number: 3 Attribute NID: 400 , Name: role Role Attribute syntax RoleSyntax Consumed by the AC verifier Multiple values allowed : yes Values: 1 Printing value: 0 -- roleAuthority [Optional] : Present roleName [MUST|URN]: URI:it.uc3m.es:administrator Extensions: Number of extensions present : 1 NID: 287, ac-auditEntity Critical: Yes Data:61:75:64:69:74:2d:69:6e:66:6f: Signature: Signature Algorithm: sha1WithRSAEncryption 0e:40:4f:85:72:a2:15:ef:3c:f9:c3:54:74:64:bf:6e:e7:b3: 14:21:70:22:50:fa:16:73:a7:dc:8c:8b:e8:41:1c:ae:90:df: 6d:11:1f:24:1a:57:5c:b3:8f:ba:51:70:c3:fa:13:16:4a:30: 3e:4b:63:dd:46:ae:f2:9e:47:01:b4:17:4b:00:26:9c:e4:5b: ef:f1:bc:72:63:a4:f1:bf:ec:7b:f0:27:76:4e:24:bb:63:06: 3c:67:f4:bc:f3:62:ce:53:94:ad:41:4c:36:11:9c:21:a2:f7: e5:2d:7f:6c:6e:7b:e4:4b:ed:22:4f:de:80:d8:8c:61:20:ce: d0:c3 AC Version= v2, Issuer Information --
Re: [openssl-dev] Regarding extended key usage extension implementation which differs from RFC 2459
Bonsoir, Hodie VI Id. Iun. MMVII est, durgaprasad jammula scripsit: This question is regarding the extended key usage extension implementation which differs from the specification [RFC 2459]. I read RFC 2459 in http://www.faqs.org/rfcs/rfc2459.html section 4.2.1.13 Extended key usage field. The corresponding paragraph of the RFC3280 (RFC2459 is obsolete, and superseded by RFC3280) reads: If the extension is present, then the certificate MUST only be used for one of the purposes indicated. RFC3280 is much more clear and unambigous than RFC2459. -- Erwann ABALEA [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Performance on IA64 using icc vs gcc
Hello, Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? Thanks -- Iain Morgan cfe2.imorgan apps/openssl speed aes bf rc4 md5 sha 2/dev/null OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Jun 8 10:46:48 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 8388.37k27899.28k73067.45k 123142.98k 153932.33k sha1 10270.44k33538.23k93979.13k 171431.58k 224889.51k rc4 248141.11k 299502.68k 312819.11k 316454.57k 317876.62k blowfish cbc 52879.87k56659.39k57974.95k58306.56k58335.11k aes-128 cbc 56603.67k78418.22k86639.62k89007.75k88984.23k aes-192 cbc 53353.86k72285.93k79266.68k81229.82k81267.37k aes-256 cbc 50445.43k67040.72k72999.08k74656.43k74604.54k sha256 10808.77k29896.92k62069.85k84877.31k95065.43k sha5127113.80k28534.17k72103.59k 134958.08k 181021.35k cfe2.imorgan $NOBACKUP/build/bin/openssl speed aes bf rc4 md5 sha 2/dev/nul OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Jun 8 09:27:49 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: icc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt -i-static -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 5835.63k20437.19k60845.48k 119983.98k 166928.38k sha1 6356.02k19805.21k63273.44k 140241.24k 216834.46k rc4 247902.49k 299131.32k 314115.67k 317933.50k 318111.74k blowfish cbc 50625.69k59182.33k61785.80k62476.09k62615.65k aes-128 cbc 47999.54k51204.48k52011.06k52207.27k51920.38k aes-192 cbc 45619.43k48507.73k49234.01k49402.50k49119.23k aes-256 cbc 43471.76k46080.66k46732.78k46890.42k46632.80k sha2566729.22k21080.31k50995.71k79001.82k94085.12k sha5124036.13k16274.26k48357.42k 109740.71k 174342.74k __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance on IA64 using icc vs gcc
Iain Morgan wrote: Hello, Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? How about if you use something other than -O2 with icc compared to the -O3 on gcc? That could I would think affect the 'C' stuff but shouldn't affect the assembly stuff though (although who knows, I'm just a networking guy...) is the assembly stuff such that it is still done with icc as the compiler rather than gcc? rick jones __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Linux version of Attribute certificate API
In message [EMAIL PROTECTED] on Fri, 8 Jun 2007 15:49:43 +0200, Daniel Diaz Sanchez [EMAIL PROTECTED] said: dds I have compiled the Attribute Certificate API on Linux and it is dds working with OpenSSL 0.9.8a (I didn't check other versions) Oh, really cool. I've taken it upon myself to have a look and make sure to get ACs implemented in OpenSSL during the summer. I've allocated the first whole week of July to do it. I'll get back to you then. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Performance on IA64 using icc vs gcc
Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? You should compare with the best optimization flags for each compiler. I don't see any of the typical icc optimization flags used, like -ip, -march=pentium4, -msse3, -xP, or whatever is appropriate for your CPU. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Performance on IA64 using icc vs gcc
Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? Here's what I get doing a similar test. P3-1Ghz machine. OpenSSL 0.9.8d 28 Sep 2006 built on: Fri Jun 8 17:02:33 PDT 2007 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc420 -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -march=pent ium3 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PAR T_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 5931.24k20709.35k60287.32k 116997.46k 159391.74k sha1 5550.15k17675.63k44248.15k70832.13k 85983.23k sha5121224.25k 4897.15k 8170.41k11913.22k 13757.10k OpenSSL 0.9.8d 28 Sep 2006 built on: Fri Jun 8 17:04:17 PDT 2007 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: icc91038 -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIA N -DTERMIO -O3 -xK -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -D OPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 6958.21k24528.05k68030.50k 124347.11k 161808.25k sha1 6404.12k19898.15k47526.49k72804.35k 86343.68k sha5121390.74k 5584.36k 8995.75k12954.28k 14846.63k It could be your compiler options. It could be your choice of gcc version. It could be something quirky about your hardware. Mostly, I think it's the compiler flags you passed to icc. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance on IA64 using icc vs gcc
On Fri, Jun 08, 2007 at 17:00:37 -0700, David Schwartz wrote: Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? You should compare with the best optimization flags for each compiler. I don't see any of the typical icc optimization flags used, like -ip, -march=pentium4, -msse3, -xP, or whatever is appropriate for your CPU. DS The options used in the icc case were simply those set by ./Configure linux-ia64-icc. The one option that I added was -i-static to force static linking to libimf. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
