Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++5.5
> > [[EMAIL PROTECTED] - Fri Jan 3 06:45:12 2003]: > > > > > I'm trying to compile 0.9.7 with Borland C++ 5.5 and NASM 0.98.35 on > > > Windows XP Professional SP1 with all updates. > > > > > > .\crypto\x509\x_all.c: > > > Error E2450 .\crypto\x509\x_all.c 72: Undefined structure > > 'ASN1_ITEM_st' This same error happpened for me when compiling with Builder 5. I haven't checked Builder 6 yet. This is the one outstanding error for Builder 5 for which I still have local patches - I did submit a working fix for this some time ago, but it was kind-of controversial and didn't make it in. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Weakness (bug?) in blowfish
David McNab wrote: 5) I chose OpenSSL's Blowfish because it's fast, simple, and (through CFB mode and stored IV/count) can encrypt/decrypt arbitrary-sized blocks, and thus doesn't have that annoying n-byte granularity. Can I use OpenSSL's BF with confidence? What constraints should I observe? You could avoid this problem by using the SHA1 hash (or MD5 hash) of your ASCII key as the Blowfish key. This would avoid the problem you're referring to since the hashes for 'fred' and 'fredfred' would be different. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: More DH questions
Nils Larsch wrote: What could be the possible problem where I am getting a different secret & pub_key every time? Perhaps you should read a textbook about cryptography. I recommend Practical Cryptography from Bruce Schneier and Nils Fergusson in this respect - it has a fine description of DH key exchange and the mathematics behind it. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #743] Bug in AES_cbc_encrypt
Hi, [EMAIL PROTECTED] via RT wrote: The function AES_cbc_encrypt has a bug when its input and output parameters are the same which causes it to incorrectly update the IV. All other OpenSSL ..._cbc_encrypt functions happily accept input==output, I don't see a valid reason why AES would be the exception. The attached patch fixes the problem, but a revisitation of the AES CBC functions may be in order in order to optimise (I'm sure it's got to be possible to encrypt/decrypt without memcpying so much) It's 6 weeks since I submitted this patch. Are there objections to it, or should I just sit patiently until it gets to the top of someone's queue? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #743] Bug in AES_cbc_encrypt
Richard Levitte via RT wrote: I was notified today of the existence of this ticket. My appologies for missing it. The patch included in this ticket was applied almost two months ago, so I'm resolving this ticket. Cool, thanks (my apologies for not checking whether the patch was in fact applied :-) -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES_CBC decryption
Richard Levitte - VMS Whacker wrote: In message <[EMAIL PROTECTED]> on Fri, 19 Dec 2003 10:49:49 -0600, "Stephen Sprunk" <[EMAIL PROTECTED]> said: stephen> stephen> Minor bug: the AES CBC function doesn't correctly handle stephen> in==out. Is that something you have actually observed, or are you guessing? As far as I can read the code, in==out should be supported, or we would remove some of the memcpy() in there... If what you say is true and reproducable, I'd like to know, because that's a bug that I wish to correct. AES CBC didn't support in==out until my recent patch (RT #743) was applied. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BCB5 compilation
Hi,
The attached patch is necessary in order to compile bn_nist.c with
Borland Builder 5. It turns off the "Condition is always true" and
"Unreachable code" warnings, without which the compiler eventually drops
out with a "Too many warnings" error.
--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
--- util/pl/BC-32.pl4 Nov 2002 06:26:37 - 1.14
+++ util/pl/BC-32.pl26 Aug 2005 11:47:30 -
@@ -18,7 +18,7 @@
$tmp_def="tmp32";
$inc_def="inc32";
#enable max error messages, disable most common warnings
-$cflags="-DWIN32_LEAN_AND_MEAN -q -w-aus -w-par -w-inl -c -tWC -tWM
-DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp ";
+$cflags="-DWIN32_LEAN_AND_MEAN -q -w-ccc -w-rch -w-aus -w-par -w-inl -c -tWC
-tWM -DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp ";
if ($debug)
{
$cflags.="-Od -y -v -vi- -D_DEBUG";
Re: BCB5 compilation
Jon Bright wrote: The attached patch is necessary in order to compile bn_nist.c with Borland Builder 5. It turns off the "Condition is always true" and "Unreachable code" warnings, without which the compiler eventually drops out with a "Too many warnings" error. ...and I should probably mention that this was for 0.9.7 HEAD. I'm not sure if it applies or is needed for 0.9.8. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: BCB5 compilation
Hi,
Attached is an updated patch for building with Borland C++Builder 5.
This turns off the same two warnings as before, defines _strnicmp,
enabling one of the test programs to build, and changes the NASM
assembly generation to generate a "class=code" directive for segments.
Without the "class=code" directive, the linker ends up putting the
assembler in the data segment, which sometime later hits
WinXPSP2/Windows Server 2003's Data Execution Prevention, since the data
segment is loaded without the execute bit set.
--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
--- crypto/perlasm/x86nasm.pl 26 Mar 2005 19:32:31 - 1.2.8.8
+++ crypto/perlasm/x86nasm.pl 26 Aug 2005 22:07:44 -
@@ -221,6 +221,6 @@
sub main'file
{
- push(@out, "segment .text use32\n");
+ push(@out, "segment .text use32 class=code\n");
}
--- util/pl/BC-32.pl17 May 2004 04:28:30 - 1.11.2.5
+++ util/pl/BC-32.pl26 Aug 2005 22:07:10 -
@@ -18,7 +18,7 @@
$tmp_def="tmp32";
$inc_def="inc32";
#enable max error messages, disable most common warnings
-$cflags="-DWIN32_LEAN_AND_MEAN -q -w-aus -w-par -w-inl -c -tWC -tWM
-DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp ";
+$cflags="-DWIN32_LEAN_AND_MEAN -q -w-ccc -w-rch -w-aus -w-par -w-inl -c -tWC
-tWM -DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp
-D_strnicmp=strnicmp ";
if ($debug)
{
$cflags.="-Od -y -v -vi- -D_DEBUG";
