Re: camellia and uint
Hi, On Thu, 20 Jul 2006 08:31:35 -0600 The Doctor [EMAIL PROTECTED] wrote: Upon this mornings compile on my BSD boxes, camellia was found to have uint's and inttypes.h which has to be corrected to U-int's and commenting out respectively. I think you can compile on the BSD with Camellia code which is included in OpenSSL after Dec. 2nd. Please try with it. Best regards, -- Masashi FUJITA MS Solution Businnes Group, NTT Software __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: what the heck is with camellia update?
Hi, On Thu, 20 Jul 2006 17:02:37 +0200 Gisle Vanem [EMAIL PROTECTED] wrote: One other thing is that cmll_loc.h includes intypes.h for non-MSCV targets. This header is not omni-present. A patch for djgpp at least: I think you can compile on non-MSVC with Camellia code which is included in OpenSSL after Dec. 2nd. Please try with it. Best regards, -- Masashi FUJITA MS Solution Businnes Group, NTT Software __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1419] 0.9.8d on OpenVMS fails Camellia test
Hi, On Tue, 24 Oct 2006 18:37:49 +0200 (METDST) Anthony Crowson via RT [EMAIL PROTECTED] wrote: Building OpenSSL 0.9.8d with DECC (Compaq C V6.5-001 on OpenVMS Alpha 8.2) using makevms.com, the test suite fails on Camellia as shown: I think it can run appropriately on Camellia code which is included in OpenSSL after Dec. 2nd. Though we don't have OpenVMS unfortunately, please try with it. Testing cipher CAMELLIA-128-ECB(encrypt/decrypt) Key 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 Plaintext 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 Ciphertext 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43 Ciphertext mismatch Got d7 94 e6 7a b5 45 77 73 93 82 23 56 f6 ae 06 71 Expected 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43 Rebuilding with OPENSSL_NO_ASM still fails. After disabling Camellia (via define OPENSSL_NO_CAMELLIA YES) and rebuilding, all other tests apparently pass. $ mc ENVDATA1:[SPELIB.OPENSSL.OPENSSL-0_9_8D.AXP.EXE.APPS]OPENSSL.EXE version -a OpenSSL 0.9.8d 28 Sep 2006 built on: 24-OCT-2006 13:31:18.23 platform: VMS options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: OPENSSLDIR: N/A This is a bug report for information: I have no currently known need for Camellia. Regards, Anthony Crowson Best regards, -- Masashi FUJITA MS Solution Businnes Group, NTT Software __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1458] garbage-in garbage-out - was OCSP response nonce extension encoding not DER
Looks like OpenSSL has a problem/feature of garbage-in garbage-out. It's a problem because it does not comply with the RFC and a feature because it lets OpenSSL work with broken clients. My OCSP request from some time ago had the encoding error of encoding the default values and it looks like OpenSSL just returns the encoding of the nonce extension that it got rather than re-encoding it as DER. Actually the encoding can be BER but the ... signature SHALL be computed on the hash of the DER encoding ... is clear. This explains why OpenSSL now works for me - because the request (with nonce) from my end is now DER encoded. Regards, Simon McMahon Simon McMahon/Australia/Contr/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/10/2007 12:56 PM Please respond to openssl-users@openssl.org To openssl-users@openssl.org cc Subject OCSP response nonce extension encoding not DER Hi, Just saw some weirdness in OCSP response encodings with a nonce extension. The OCSP response has this for the extensions: A1 1E 30 1C 30 1A 06 09 2B 06 01 05 05 07 30 01 02 01 01 00 --- 04 0A 04 08 A5 10 18 67 E5 A4 8B 2C The sencond last item is the 'false' (00) for the 'critical' field. 'false' is the default value (rfc 3280) so should not appear in a DER encoding. Here is another OCSP response extension and this is how it should be for DER: A1 1B 30 19 30 17 06 09 2B 06 01 05 05 07 30 01 02 04 0A 04 08 D4 4C 29 A8 C6 1A 16 56 The 'false' is not there. Note that afaik both were produced by the same version of OpenSSL but at different times. I haven't been able to reproduce the one containing the 'false' and since I cant reproduce a response like this, and the most recent one I produced was OK I'm not 100% sure what is going on. I only noticed this because my validitator used to accept the first response, now it rejects it. It reencodes the resp to DER, before checking the sig. RFC 2560 says the signature SHALL be computed on the hash of the DER encoding The error I get is a bad signature. The entire ocsp response is attached. Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1458] garbage-in garbage-out - was OCSP response nonce extension encoding not DER
This is to work around broken encodings and not just for OCSP. OpenSSL effectively uses the received encoding when computing signatures instead of converting it to DER. OpenSSL isn't alone in doing this and it is fairly common practice. In the past several (rather important) certificates would have been unusable because they would technically have broken signatures if DER conversion had taken place. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1459] Bug in quoting string expressions
The attached patch fixes an incorrect handling of special characters. Patch is against 0.9.8d. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OPENSSL_NO_FP_API, OPENSSL_NO_STDIO
Can someone explain the use of these two macros? There seem to be quite a few places where they are missing. For example... crypto/cryptlib.c crypto/conf/conf.h crypto/pem/pem.h crypto/engine/eng_openssl.c crypto/bio/bss_dgram.c crypto/rand/randfile.c crypto/asn1/a_strex.c crypto/x509v3/x509v3.h crypto/pem/pem_pk8.c I don't quite understand why one is used instead of the other. b.c. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Configure flags vs. depflags, 0.9.7 vs. 0.9.8
In 0.9.7, Configure no-ocsp would set CFLAG, DEPFLAG, write the OPENSSL_NO_OCSP define to opensslconf.h, and prune ocsp from the crypto subdirs. In 0.9.8, it no longer sets CFLAG. Was this intentional? Unfortunately, it means the compile guards in crypto/x509v3/v3_ocsp.c don't work. The macro isn't defined until the config is sourced, which is too late. I'm not sure if this is a problem with v3_ocsp.c (the compile guard should be moved down), or with Configure (the compile options should be added to CFLAG). b.c. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Escape sequence for Configure script's colon-delimited lines.
Hello: I am trying to customize aix-cc configuration for myself. In the Configure script in OpenSSL, the line reads as follows: aix-cc, cc:-q32 -O -DB_ENDIAN -qmaxmem=16384::-qthreaded:AIX::BN_LLONG RC4_CHAR::aix_ppc32.o::dlfcn:aix-shared::-q32:.so.\$(SHLIB_MAJOR ).\$(SHLIB_MINOR)::-X 32, I want to add a flag in the line so that it should now have -binitfini:MyFunction flag and the line should read as follows: aix-cc, cc:-q32 -O -DB_ENDIAN -qmaxmem=16384 -binitfini:MyFunction ::-qthreaded:AIX::BN_LLONG RC4_CHAR::aix_ppc32.o::dlfcn:aix-shared::-q32:.so.\$(SHLIB_MAJOR ).\$(SHLIB_MINOR)::-X 32, However, the problem is that the colon in the flag itself is treated as the delimiter. I want to know if there is any escape character (sequence) that I can use to retain the meaning of colon in flag -binitfini:MyFunction. Any help will be appreciated. Thanks, Manish Mehta Tumbleweed E-mail Firewall tumbleweed.com made the following annotations on 01/12/07, 19:28:47 -- === Tumbleweed Communications Disclaimer === This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. ==
