Problems to sign and then verify using RSA (openssl rsautl)

2002-04-12 Thread Walmir Amorim
I'm trying to sign and then verify using openssl RSA but I'm when I'm verifying I'm getting the error message: RSA operation error 1902:error:0406706C:rsa routines:RSA_EAY_PUBLIC_ENCRYPT:data greater than mod len:rsa_eay.c:364:erro I generated the private key using the command "openssl genrsa

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

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

2002-04-12 Thread Lutz Jaenicke
On Fri, Apr 12, 2002 at 09:59:58AM +0200, Pavel Tsekov wrote: > 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 ?

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 curren

Problem with mail and RFC 1700

2002-04-12 Thread Michael Bell
Hi, I read RFC 1700 and I don't see why we should get problem if we rename "internet 7" in crypto/objects/objects.txt from "mail" to "internetMail". Nobody should ever use a direct reference to these #defines. Only objects.txt would use this name and if the first user need a subtree then we simpl

Re: bug in ssl code

2002-04-12 Thread Arne Ansper
> You do not point out in which version the problem occurs. > Does it still occur with recent snapshots? sorry. my mistake. i'm still using 0.9.6b, but i checked cvs and all the bad bits are still there. arne __ OpenSSL Pro

Re: bug in ssl code

2002-04-12 Thread Lutz Jaenicke
On Fri, Apr 12, 2002 at 01:59:17AM +0300, Arne Ansper wrote: [Detailed analysis about problems with state machine/non-blocking sockets when using implicit handshake deleted] Probably Bodo has more in-depth knowledge about this than myself, but let't start discussing it anyway :-) You do not poin

Re: Bug in ssl3_read_bytes()

2002-04-12 Thread Bodo Moeller
Alex Pankratov <[EMAIL PROTECTED]>: > the following problem is present in 0.9.6 and 0.9.6c. > > It is possible to put server code into the internal infinite > loop in ssl3_read_bytes() by sending the following data from > the client right after establishing TCP connection: > > 01 03 01 00 01 00

Re: bug in ssl code

2002-04-12 Thread Bodo Moeller
Arne Ansper <[EMAIL PROTECTED]>: [...] > okey, the bug: > > ssl3_read_internal function has special treatment for situations when > renegotiation is going on and the handshake and data packets are arriving > in random order. > > now, if i have a non-blocking socket on server side and i use BIO

Re: Futher debug of possible race condition in 0.9.6b/c

2002-04-12 Thread Dax Kelson
On Fri, 8 Feb 2002, Lutz Jaenicke wrote: > On Fri, Feb 08, 2002 at 01:53:11AM -0700, Dax Kelson wrote: > > > > sshd/ftpd/telnetd -> pam_ldap -> libldap -> libssl/libcrypto > > > > To recap, when my dual processor Pentium III is idle, I *always* get a > > return value of 0 from SSL_connect. If

Re: Futher debug of possible race condition in 0.9.6b/c

2002-04-12 Thread Dax Kelson
If I run "strace -f -p 'PID of getty', and then login, it works (as I described before). Here is the (much longer) ssldump output. 10.1.0.57 is the client, 10.1.0.3 is the server # ssldump -n host 10.1.0.57 and port 389 New TCP connection #1: 10.1.0.57(33051) <-> 10.1.0.3(389) 1 1 0.0107 (0

Re: Futher debug of possible race condition in 0.9.6b/c

2002-04-12 Thread Geoff Thorpe
Hi Dax, I don't know if I can help much here except to cast a second pair of eyes over this - but as you seem to be running short of places to look ... On Saturday 13 April 2002 12:51, Dax Kelson wrote: > On Fri, 8 Feb 2002, Lutz Jaenicke wrote: > > On Fri, Feb 08, 2002 at 01:53:11AM -0700, Dax

Re: Futher debug of possible race condition in 0.9.6b/c

2002-04-12 Thread Dax Kelson
> > I took a closer look at this second TCP session with tethereal. > > > > Here is it: > > > > 10.1.0.57 is the client, 10.1.0.3 is the server > > > > 41 6.48884610.1.0.57 -> 10.1.0.3 TCP 33041 > 389 [SYN] > > Seq=2664529133 Ack=0 Win=5840 Len=0 42 6.489711 10.1.0.3 -> 10.1.0.57

Re: Futher debug of possible race condition in 0.9.6b/c

2002-04-12 Thread Geoff Thorpe
Hi there, > > yet your tethereal output is interlaced with some LDAP > > debugging messages, one is the server sending a "Bad message type" > > message to the client and the client sending a "LDAP Invalid LDAP packet" > > message back to the server?? How is it possible that LDAP messages are > >

Re: Futher debug of possible race condition in 0.9.6b/c

2002-04-12 Thread Dax Kelson
On Fri, 2002-04-12 at 22:30, Geoff Thorpe wrote: > > Can you get any log messages from the server as to "errors" it is reporting > at the time these connections are being dumped that are *not* reported when > the connections are going OK? It could be a race condition above the LDAP > layer, or