Re: BUG? CreateToolhelp32Snapshot not on NT4

2002-05-29 Thread Pavel Tsekov

Hello Noel,

You may as well try to find a way to workaround this problem for your
platform, instead of just removing the offending code (which may break
other things) ...

This is taken from the MSDN library description of
CreateToolhelp32Snapshot():

  Windows NT/2000/XP: Included in Windows 2000 and later.
  Windows 95/98/Me: Included in Windows 95 and later.
  Header: Declared in Tlhelp32.h.
  Library: Use Kernel32.lib.

Ok so it is not in WinNT 4... but take a look on this thread from the
cygwin mailing list:

http://www.cygwin.com/ml/cygwin/2002-05/msg01731.html

This is a direct link to a message which might help you. You can read
the whole thread if interested.

Tuesday, May 28, 2002, 6:49:31 PM, you wrote:

NBK We've made a Windows app with OpenSSL-0.9.6c but it fails to run on NT4.
NBK The problem:

NBK The procedure entry point CreateToolhelp32Snapshot could not be located
NBK in the dynamic link library KERNEL32.dll

NBK Grepping through the source reveals that the only calls to
NBK CreateToolhelp32Snapshot are in openssl-0.9.6c/crypto/rand/rand_win.c.

NBK Has anyone else faced this problem?  I'm going to cut out
NBK CreateToolhelp32Snapshot and post a patch.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re[2]: Cannot compile open openssl-0.9.6d-beta1

2002-05-04 Thread Pavel Tsekov

Hello Axel,

Saturday, May 04, 2002, 12:37:33 AM, you wrote:

AHS Hi Lutz!

AHS On Fri, 03 May 2002, Lutz Jaenicke wrote:

 On Fri, May 03, 2002 at 10:01:52PM +0200, Axel H. Siebenwirth wrote:
  unfortunately openssl-0.9.6d-beta1 won?t compile on my system. I have this
  strange feeling that it?s because of my gcc:
  
  Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
  Configured with: /usr/local/src/gcc/gcc_3.1.x/configure
  --enable-languages=c,c++Thread model: single
  gcc version 3.1 20020429 (prerelease)
  
  When linking openssl, the linker stops with an error:
  
  gcc -o openssl -DMONOLITH -I../include -fPIC -DTHREADS -D_REENTRANT
  -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer
  -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM openssl.o verify.o asn1pars.o
  req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
  crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o
  s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o
  version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o
  -L.. -lssl -L.. -lcrypto -ldl
  collect2: ld terminated with signal 11 [Segmentation fault], core dumped
  make[2]: *** [openssl] Error 1
 
 This definitely is a problem with your build tools. You seem to be
 using gnu-ld (from binutils!?) and it is failing.

AHS GNU ld 2.11.90.0.29
AHS Copyright 2001 Free Software Foundation, Inc.

AHS Do you have any advice on what I could try to do?

1. Repost your original message to the binutils bugs mailing list -
[EMAIL PROTECTED] .

2. Try to debug ld :)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [PATCH] Re: Question on EVP encryption/decryption routines

2002-05-03 Thread Pavel Tsekov

Is there any chance that somone will comment on this topic anytime
soon ?

PT Does the attached oneliner make sense ? IMO it doesnt break anything,
PT but allows reusing the EVP_CIPHER_CTX in calls to EVP_EncryptUpdate,
PT after EVP_EncryptFinal is called.

PT Any comments greatly appreciated :)

PT The diff is against the released 0.9.6c version of the OpenSSL
PT library.

PT Currently EVP_Encrypt* interface doesnt support
PT encryption of multiple data streams with a single
PT symmetric key. Is there any chance patches to
PT allow this to be accepted in the official OpenSSL
PT codebase ? Currently I'm thinking to modify EVP_EncryptFinal
PT so it leaves the EVP_CIPHER_STATE in a consistent state
PT after finishing its work.

PT Any comments on this ? I am aware of the fact that encrypting
PT multiple data streams with a single key is not such a good idea
PT of a security point of view.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re[2]: [PATCH] Re: Question on EVP encryption/decryption routines

2002-05-03 Thread Pavel Tsekov

Hello Lee,

Friday, May 03, 2002, 4:21:04 PM, you wrote:

DL I'm not on the dev team or anything, but I don't understand how you could have 
*ever* successfully encrypted multiple streams with the same EVP context??? Just the 
IV's alone would have been
DL screwed up for CBC ciphers and stream ciphers like RC4 would completely break.

ECB won't - IV isn't needed there... I didn't say its a complete solution. Still it 
doesnt
break nothing as far as I can tell. More changes has to come of
course... Still what exactly this patch does is:

I EVP_UpdateEncrypt is called EVP_EncryptFinal intermidiate data in
the temporary buf in the context wont be considered a part of the new
data stream.

DL Unless, of course, you decrypted in *exactly* the same sequence of streams as you 
encrypted, in which case, each individual stream would be incorrectly encrypted.


DL still, I don't see how this could have ever worked.

DL -lee

DL -Original Message-
DL From: Pavel Tsekov [mailto:[EMAIL PROTECTED]]
DL Sent: Friday, May 03, 2002 5:27 AM
DL To: [EMAIL PROTECTED]
DL Subject: Re: [PATCH] Re: Question on EVP encryption/decryption routines


DL Is there any chance that somone will comment on this topic anytime
DL soon ?

PT Does the attached oneliner make sense ? IMO it doesnt break anything,
PT but allows reusing the EVP_CIPHER_CTX in calls to EVP_EncryptUpdate,
PT after EVP_EncryptFinal is called.

PT Any comments greatly appreciated :)

PT The diff is against the released 0.9.6c version of the OpenSSL
PT library.

PT Currently EVP_Encrypt* interface doesnt support
PT encryption of multiple data streams with a single
PT symmetric key. Is there any chance patches to
PT allow this to be accepted in the official OpenSSL
PT codebase ? Currently I'm thinking to modify EVP_EncryptFinal
PT so it leaves the EVP_CIPHER_STATE in a consistent state
PT after finishing its work.

PT Any comments on this ? I am aware of the fact that encrypting
PT multiple data streams with a single key is not such a good idea
PT of a security point of view.

DL __
DL OpenSSL Project http://www.openssl.org
DL Development Mailing List   [EMAIL PROTECTED]
DL Automated List Manager   [EMAIL PROTECTED]
DL __
DL OpenSSL Project http://www.openssl.org
DL Development Mailing List   [EMAIL PROTECTED]
DL Automated List Manager   [EMAIL PROTECTED]



-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re[3]: [PATCH] Re: Question on EVP encryption/decryption routines

2002-05-03 Thread Pavel Tsekov

DL I'm not on the dev team or anything, but I don't understand how you could have 
*ever* successfully encrypted multiple streams with the same EVP context??? Just the 
IV's alone would have been
DL screwed up for CBC ciphers and stream ciphers like RC4 would completely break.

PT ECB won't - IV isn't needed there... I didn't say its a complete solution. Still 
it doesnt
PT break nothing as far as I can tell. More changes has to come of
PT course... Still what exactly this patch does is:

PT I EVP_UpdateEncrypt is called EVP_EncryptFinal intermidiate data in
+- If   +- after
PT the temporary buf in the context wont be considered a part of the new
PT data stream.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[PATCH] Re: Question on EVP encryption/decryption routines

2002-05-01 Thread Pavel Tsekov

Does the attached oneliner make sense ? IMO it doesnt break anything,
but allows reusing the EVP_CIPHER_CTX in calls to EVP_EncryptUpdate,
after EVP_EncryptFinal is called.

Any comments greatly appreciated :)

The diff is against the released 0.9.6c version of the OpenSSL
library.

PT Currently EVP_Encrypt* interface doesnt support
PT encryption of multiple data streams with a single
PT symmetric key. Is there any chance patches to
PT allow this to be accepted in the official OpenSSL
PT codebase ? Currently I'm thinking to modify EVP_EncryptFinal
PT so it leaves the EVP_CIPHER_STATE in a consistent state
PT after finishing its work.

PT Any comments on this ? I am aware of the fact that encrypting
PT multiple data streams with a single key is not such a good idea
PT of a security point of view.


evp_enc.c.diff
Description: Binary data


Re: [PATCH] Re: Question on EVP encryption/decryption routines

2002-05-01 Thread Pavel Tsekov

Sorry for the double post - it seems like the ml software sets the
reply to addres to the ml address and I've pressed 'Reply All'. I'll
be more carefull in the feature :)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Question on EVP encryption/decryption routines

2002-04-30 Thread Pavel Tsekov

Hello,

I have a simple question:

Currently EVP_Encrypt* interface doesnt support
encryption of multiple data streams with a single
symmetric key. Is there any chance patches to
allow this to be accepted in the official OpenSSL
codebase ? Currently I'm thinking to modify EVP_EncryptFinal
so it leaves the EVP_CIPHER_STATE in a consistent state
after finishing its work.

Any comments on this ? I am aware of the fact that encrypting
multiple data streams with a single key is not such a good idea
of a security point of view.

Thanks! :)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Problems with installation

2002-04-26 Thread Pavel Tsekov

Hello Arturo,

Wednesday, April 24, 2002, 11:26:56 PM, you wrote:

[snip]

AMG /usr/ucb/cc:  language optional software package not installed
AMG *** Error code 1

Since you don't provide any detail about the build system I have to
guess. My first guess is that you're trying to compile on some
Solaris/SunOS box. My second guess is that you're using the Sun
compiler and your problem has nothing to do with OpenSSL, but with
the compiler itself. Since I don't know nothing about the Sun compiler
I would point you to the compiler manual - I'm sure you'll find the
description of the error message there.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Fwd: [BUG suggested PATCH] EVP_DecodeUpdate 0.9.6b 0.9.6c

2002-04-12 Thread Pavel Tsekov

This is a forwarded message
From: Pavel Tsekov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Thursday, April 11, 2002, 12:39:59 PM
Subject: [BUG  suggested PATCH] EVP_DecodeUpdate 0.9.6b  0.9.6c

Any comments on this ? I posted on openssl-users but got no response
at all - either confirming on denying...

===8==Original message text===
Date: Thu, 11 Apr 2002 12:39:59 +0200
From: Pavel Tsekov [EMAIL PROTECTED]
X-Mailer: The Bat! (v1.53d)
Reply-To: Pavel Tsekov [EMAIL PROTECTED]
Organization: Syntrex, Inc.
X-Priority: 3 (Normal)
Message-ID: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: [BUG  suggested PATCH] EVP_DecodeUpdate 0.9.6b  0.9.6c
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=--C1A915C16EC5CF

Hello, there! :)

My colleague Nedelcho Stanev and myself have identified what we would
think to be a bug (or a flaw) in the EVP_DecodeUpdate() routine. We
were trying to read base64 encoded data with the base64 BIO which has
the 'next' member pointed to membuf BIO in which we write the encoded
data. So far so good ... Eventually it turned up that some of the data
we pass to the BIO chain is properly decoded while other not - or more
properly would be to say - partially decoded. We tried to debug the
problem and here is what we have found:

The EVP_DecodeUpdate() routine errnously returns 0 (EOF) if the buffer
passed it, ends with CRLF and EVP_DecodeBlock() has just processed
the data upto the ending CRLF.

Attached is a patch and a testcase. I tried to follow the coding style
and to make the change not intrusive :) though its a very small change
:)

Here is how to reproduce:

1. Base64 encode a file lets say  200kb
2. unix2dos the output
3. Use the attached testcase to decode the file

===8===End of original message text===


encode.c.patch
Description: Binary data


bio.cpp
Description: Binary data


Re[2]: Fwd: [BUG suggested PATCH] EVP_DecodeUpdate 0.9.6b 0.9.6c

2002-04-12 Thread Pavel Tsekov

Hello Lutz,

Friday, April 12, 2002, 10:12:04 AM, you wrote:

 Any comments on this ? I posted on openssl-users but got no response
 at all - either confirming on denying...

LJ Your posting is still in my incoming queue.
LJ Obviously my team mates normally dealing with EVP issues are currently
LJ too busy to take care of it. But it won't be forgotten :-)

Ok - forgive me if I was too pushy :)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]