[openssl.org #328] DH_compute_key incompatable with PKCS #3
Hi, It seems that DH_compute_key is slightly incompatable with PKCS #3, if the derived secret z is too small. In particular, section 8.3 of PKCS #3 Integer-to-octet-string conversion, specifies that that output of the operation should be exactly k bytes long (where k is the number of bytes in the prime p). This seems to be regardless of how big the derived secret actually is (for example if z ends up being 5, and p is ~ 2^512, the output should still be 64 bytes long, with 63 of the leading bytes being 0). OpenSSL does not do it this way: it coverts the shared secret integer into a byte string of a length equivalent to the number of significant bytes in the shared integer. I initially noticed this while reading the dh manpage, and confirmed it by reading dh_key.c as included in openssl-0.9.6g I believe this can be fixed by memset'ing the key parameter to all 0s before doing any operations, then returning DH_size(dh) regardless of the size of the resulting integer. Regards, Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #329] Shared libraries on cross platform
I'm compiling SSL for Arm linux. I'm using the uclibc wrapper around arm-linux-gcc so that gcc is arm-uclibc-gcc. There are appropriate symlinks for all tools with all of them prefixed by arm-uclibc-. My machine is an i686 running Slackware 8.1 To compile I do: ./Configure linux-elf-arm shared make CC=arm-uclibc-gcc RANLIB=arm-uclibc-ranlib AR=arm-uclibc-ar r The scripts to determine the ld seem to be hard coded to use gcc, rather than CC, so that it tries to use the system i386 ld rather than arm-uclibc-ld. This then baulks at the incorrect elf format (arm instead of i386). I tried passing a parameter to make LD=arm-uclibc-ld but that still fails. I hope that makes sense The neatest option seems to me to accept a LD parameter to make(LD has to be a variable in the makefile) or to use autoconf/automake to build, which would also have the advantage that the build directory can be a different directory than the source directory, which is useful if you use the same source to build for multiple target architectures as I do. TIA, Andy __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?
On Thu, 31 Oct 2002, Frédéric Giudicelli via RT wrote: ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer (normal) INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN as issuer (normal) A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer (not normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of this certificate is INTERMEDIATE CA and not ROOT CA. OpenSSL is right. To use 'human' terms, to point to your father, you have to give your grandfather's name and the exact number of your father among all your grandfather's children. That's how it's done, and that's how it has to be done. -- Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5 - Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour fonctionner,à force,en France de refuser tout rapport sain avec l'argent,l'on riqsque de tuer ce nouvel outil. -+- AA in: Guide du Neuneu d'Usenet - Le netétiquette du riche -+- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?
On Sat, 2 Nov 2002, Vadim Fedukovich wrote: On Fri, Nov 01, 2002 at 12:51:24AM +0100, Frédéric Giudicelli via RT wrote: Well Microsoft support tells me it's openssl's fault, and you tell me it's microsoft's ? It's dead end, what am I supposed to tell my clients ? Well, Microsoft and openssl are not the only code available. Would you accept a well-done one from IBM? The SET wallet was tested to accept certificates hierarchy with AKI extension in merchant certificate referring brand CA, not merchant CA name. You're right, that's how it's done in the SET hierarchy. The keyIdentifier is not used, the only valid content for the authorityKeyIdentifier is the issuer's name of the issuer certificate, packed with the issuer's certificate serial number. -- Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5 - Et puis, je sais que ça ne se fait pas de reprendre sur l'orthographe, mais l'usage Usenetien veut qu'on écrive scançeur. En ajoutant fâssiste, pour faire bonne mesure. -+- XH in http://neuneu.mine.nu : L'heptalingue sans peine -+- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?
On Fri, 1 Nov 2002, [iso-8859-1] Frédéric Giudicelli wrote: Well Microsoft support tells me it's openssl's fault, and you tell me it's microsoft's ? It's dead end, what am I supposed to tell my clients ? Well. Since Microsoft's history if full of bugs, security problems, and non-comformity to the standarts, then Microsoft is more likely to be guilty. ;) Well... altough PKIX recommends the use of the authorityKeyId, and that the French Government says you must to have this extension, to be certified, I'll have to remove this extension ? No. The authorityKeyIdentifier can be used in 3 different manners, differing in the content of the extension: 1/ specify the keyIdentifier contained in the subjectKeyIdentifier extension of the issuer certificate 2/ specify the issuer name of the issuing certificate, with the serial number of the issuing certificate (that is, identify the issuing certificate by it's father's name and the rank of the issuing certificate in all those children). 3/ both of the above contents The easiest method is the first one, of course. But that means each issuing certificate has to have a subjectKeyIdentifier extension. When it's not the case, and you *must* provide an authorityKeyIdentifier extension, then the method 2 is the only one possible. Please take into consideration that: - qualified certificates are defined by European directives, not a french law - it takes a lot more than just using the authorityKeyIdentifier extension to have a qualified certificate Hope this helps. -- Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5 - CJ Les censeurs agitent plus de vent que les moulins des Pays Bas. Tiens, je savais pas que c'étaient les moulins qui créaient le vent. -+- GR in GNU : Dame qui se shoote et sang chaud pensa -+- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #235] Bug in cryptlib.c
[[EMAIL PROTECTED] - Wed Aug 21 09:34:00 2002]: Is this the correct list to post bug reports to? Yes. There is a bug in cryptlib.c when using app locks. It is in both 0.9.6c and 0.9.7 beta 3. In 0.9.7 beta3 CRYPTO_NUM_LOCKS is 31. When requesting an app lock this code gets called: [...] Thanks for the report. I just committed a fix. Please try the next snapshot. This ticket is now resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #330] Abuse of assert() in crypto/aes/
The AES library (0.9.7-dev, 0.9.8-dev) abuses assert() to check for invalid function parameters. For aes_cbc.c, this includes the case where 'length' is not a multiple of AES_BLOCK_SIZE. For consistency with other ciphers, the library should not require 'length' to be a multiple of the block size. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #325] Open SSL on Bug on Win32
In message [EMAIL PROTECTED] on Thu, 31 Oct 2002 22:45:26 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt I would like to use your Open SSL 0.9.6 for web project for security rt purpose.. rt These are the Steps we did. rt rt 1) Downloaded the files( openssl-engine-0.9.6g.tar.gz and rt openssl-0.9.6g.tar.gz ) from http://www.openssl.org/source/ rt 2) Unzipped using Win Ace2.1 rt 3) Installed Perl from http://www.activestate.com/ActivePerl rt 4) Run Configure: [...] rt E:\FMADocs\openssl-engine-0.9.6gC:\Program Files\Microsoft Visual rt Studio .Net\ rt VC7\bin\NMAKE -f ms\ntdll.mak rt rt OutPut(last few lines): rt rt nul rt .\apps\testdsa.h rt 1 個のファイルをコピーしました。 rt copy nul+ .\apps\testrsa.h tmp32\testrsa.h rt nul rt .\apps\testrsa.h rt 1 個のファイルをコピーしました。 rt cl /Fotmp32\cryptlib.obj -Iinc32 -Itmp32 /MD /W3 /WX /G5 /Ox rt /O2 /Ob2 / rt Gs0 /GF /Gy /nologo -DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 rt -DWINNT rt /Fdout32 -c .\crypto\cryptlib.c rt 'cl' は、内部コマンドまたは外部コマンド、 rt 操作可能なプログラムまたはバッチ ファイルとして認識されていません。 rt rt (This message is displayed in Japanese, but translated into english i.e., rt Internal command or external command or program or batch file of cl rt program is not recognize) What about trying to do the following before running nmake: C:\Program Files\Microsoft Visual Studio .Net\VC7\bin\VCVARS32 If this doesn't work, look in C:\Program Files\Microsoft Visual Studio .Net\VC7\bin for any .BAT file that sets up an environment for you. You need that for CMD to be able to find the compiler (cl.exe). Please tell us if that solved it for you, and if the correct .BAT file was something else than VCVARS32.BAT, please tell us so we can mention that in our documentation. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
