On Wed, 28 Jul 2004, Andy Polyakov wrote:
> Where? I mean 'gdb ssh core' and 'where'?
The crash apparently wasn't introduced by the recent changes...
(gdb) r
Starting program: /home/share/openssl/openssh-link-with097/ssh -c aes256-cbc naga
Program received signal SIGSEGV, Segmentation fault.
0x400f8bc8 in _int_malloc () from /lib/libc.so.6
(gdb) bt
#0 0x400f8bc8 in _int_malloc () from /lib/libc.so.6
#1 0x400fa59c in malloc () from /lib/libc.so.6
#2 0x08073d53 in default_malloc_ex (num=72, file=0x80eff40 "bn_lib.c", line=328)
at mem.c:79
#3 0x080742eb in CRYPTO_malloc (num=72, file=0x80eff40 "bn_lib.c", line=328)
at mem.c:300
#4 0x08077118 in bn_expand_internal (b=0x812c1b8, words=17) at bn_lib.c:328
#5 0x080773b7 in bn_expand2 (b=0x812c1b8, words=17) at bn_lib.c:446
#6 0x080778b7 in BN_bin2bn (
s=0x812bd48 "", len=64,
ret=0x812c1b8) at bn_lib.c:617
#7 0x08078f6c in bnrand (pseudorand=0, rnd=0x812c1b8, bits=512, top=0, bottom=0)
at bn_rand.c:199
#8 0x08078fd9 in BN_rand (rnd=0x812c1b8, bits=512, top=0, bottom=0)
at bn_rand.c:212
#9 0x08071228 in dh_gen_key (dh=0x812c140, need=256) at dh.c:213
#10 0x0806f3d6 in kexgex_client (kex=0x8129cc8) at kexgexc.c:93
#11 0x0806c748 in kex_kexinit_finish (kex=0x8129cc8) at kex.c:237
#12 0x0806c65a in kex_input_kexinit (type=20, seq=0, ctxt=0x8129cc8) at kex.c:206
#13 0x0806c0d0 in dispatch_run (mode=0, done=0x8129d0c, ctxt=0x8129cc8)
at dispatch.c:93
#14 0x08055532 in ssh_kex2 (host=0x8129c78 "naga", hostaddr=0x8119780)
at sshconnect2.c:130
#15 0x08053a27 in ssh_login (sensitive=0x811a584, orighost=0xbfffeecb "naga",
hostaddr=0x8119780, pw=0x811b468) at sshconnect.c:961
#16 0x0804bd6d in main (ac=0, av=0xbfffecc4) at ssh.c:699
But the "evp_crypt: EVP_Cipher failed" problem definitely was.
> > How about merging the last known to work version from you from this
> > morning to the CVS and playing these optimization games later? :-)
>
> The last code only adds couple of sanity checks. E.g. "if (nbytes==0
> ...) return 0;" "default: return 0;" Can it be something simple like this?
You reordered most of the assembler parameters and it's now pretty hard to
get a reasonable diff between the last working version (the one from
cca midnight) and now.
> > I doubt that e.g. the IV loading optimizations would have a noticable
> > speed impact anyway...
>
> IV thing is not an optimization, but a bug fix. I mean I believe that IV
> was handled incorrectly in my previous version [which should show on
> chunks larger than REALIGN_SIZE]. Bear with me:-) A.
What was incorrect on loading IV from ctx to cdata before calling xcrypt
and saving it there afterwards? (And the code was much more readable ;-)
Michal Ludvig
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
