In dtsl1_cler_queues() , the data field of the item in
s->d1->buffered_app_data.q is incorrectly treated as hm_fragment *, it should
be DTLS1_RECORD_DATA *
--
qun-ying
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 2287ba6..7d9d91f 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -202,9 +202,12 @
In dtsl1_cler_queues() , the data field of the item in
s->d1->buffered_app_data.q is incorrectly treated as hm_fragment *, it should
be DTLS1_RECORD_DATA *
--
qun-yingdiff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 2287ba6..7d9d91f 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -202,9 +202,12 @@
Hi,
My colleague found this bug in d1_lib.c:dtls1_clear_queues().
Where the data field of the item pop from s->d1->buffered_app_data.q
is treated as hm_fragment, which result in segmentation fault when
free.
Attached is a attempted fix.
--
qun-yingdiff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
inde
Hi,
Not sure if you are aware of this entry regarding the big number operation:
http://www.securityfocus.com/archive/1/530120/30/30/threaded
I tested a few of them on my Slackware 64 14.1 (openssl 1.0.1e),
bn_ulong and bn_mod_add got Floating point exception
bn_shift got Segmentation fault
wow this is amazing look into this
http://www.finance15elnews.net/biz/?news=1625431
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
wow this is pretty crazy you should check it out
http://www.finance15dynews.net/biz/?read=5845066
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-d
wow this is intense you should give it a look
http://www.finance15cinews.net/biz/?news=6820364
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@
wow this is amazing you should look into it
http://www.finance15dynews.net/biz/?read=9549969
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@op
wow this is crazy you should look into this
http://www.spacnews.net/biz/?read=4828380
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.o
With fixed in http://cvs.openssl.org/chngview?cn=22455. seems compile ok。
--
qun-ying
- Original Message -
> From: zhu qun-ying
> To: "openssl-dev@openssl.org"
> Cc:
> Sent: Thursday, April 19, 2012 2:57:05 PM
> Subject: Re: [openssl.org #2792] Cras
I encounter compilation error when compiling for ARM platform wth OpenSSL
1.0.1a:
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="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 ec.o
Hi,
While working on DTLS, in d1_both.c:dtls1_get_message_fragment():787~866
There are calls to OPENSSL_assert (line 787):
/* read handshake message header */
i=s->method->ssl_read_bytes(s,SSL3_RT_HANDSHAKE,wire,
DTLS1_HM_HEADER_LENGTH, 0);
if (i <= 0)
> They should be sufficient. Certificates are usually public knowledge
> anyway so using weak or no encryption on them is harmless but if you
> want to use strong encryption on it you can, however some of the older
> export browsers wont import 3DES encrypted certificates.
>
> Steve.
My concern i
> I supplied some of the info for that article and I wrote PKCS#12 for
> OpenSSL so I'd say yes OpenSSL PKCS#12 implementation is reasonably
> secure with the usual precautions, i.e. not picking obvious or guessable
> passwords.
>
> OpenSSLs implementation uses high mac and encryption iteration c
I am actually quite new to the Crypto world, just about 2 months. While reading
Peter Gutmann's article on breaking PKCS#12 formatted file, I am wondering is
the implementation of OpenSSL's PKCS#12 routines subject to the same attack.
What's the most secure format could be used under OpenSSL to pr
Richard Levitte - VMS Whacker wrote:
> I've placed mkdef.diff in ftp://ftp.stacken.kth.se/pub/random/levitte,
> please apply it and try again. It also contains a corrected libray.num.
>
This one works smoothly with VC and mingw32.
Thanks.
--
(~._.~) Öì Ⱥ Ó¢ (Qun-Ying) (65) 874-67
It magically worked once for me. But then when I try to rebuild the whole thing
from scratch, (unpack the source, apply the patch, update the .num file, do the
configuration with rc5 and idea turn off), it does not work again. The generated
libeay32.def still has the entry.
--
(~._.~) Öì Ⱥ Ó¢
2K
>
> . provides a conservative non-zero value for the number of bytes of
>entropy that may be provided by each block of data fed to
>RAND_add() based upon an examination of the data structures.
>
> zhu qun-ying, would you please apply this patch and confirm to
> [EM
for Mingw32 under NT:
It fails at this stage after using the new rand_win.c, the same place that fail
on beta1.
... ...
ranlib out/libcrypto.a
(cd ./..; PERL=perl make -f Makefile.ssl asm/lib.cpp)
make[1]: Makefile.ssl: No such file or directory
make[1]: *** No rule to make target `Makefile.ssl'.
Test passed on Slackware 7.0 (kernel 2.2.17)
OpenSSL 0.9.6-beta2 17 Sep 2000
built on: Mon Sep 18 23:14:24 SGT 2000
platform: linux-elf
options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int)
blowfish(idx)
compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
Richard Levitte - VMS Whacker wrote:
> Very odd. Yes, if those -x switches were illegal, the compiler is
> probably old. But I find it really off that asm/md5-sparcv8plus.o
> didn't get built. Could you check if you got it or md5-sparcv9.o
> somewhere at all?
No. the file fail to compiled. :
OpenSSL 0.9.6-beta2 17 Sep 2000
built on: Mon Sep 18 19:52:26 SGT 2000
platform: solaris-sparcv9-gcc
options: bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowf
ish(ptr)
compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=ultr
asparc -O3 -fomit-frame-po
Error build under NT 4, VC6
cl /Fotmp32dll\rand_win.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2
/Ob2 /Gs0 /GF /Gy /nologo -DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DBN_ASM -DMD
5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll /GD -D_WINDLL -D_DLL -c .\crypto\rand
\rand_win.c
rand_win.c
.\cr
Richard Levitte - VMS Whacker wrote:
>
> From: zhu qun-ying <[EMAIL PROTECTED]>
>
> qyzhu> Line 8 of file util/pl/Mingw32.pl
> qyzhu> $rm='rem'; # use 'rm -f' if using GNU file utilities
> qyzhu> ^-- should change to somthing more meanin
Line 8 of file util/pl/Mingw32.pl
$rm='rem'; # use 'rm -f' if using GNU file utilities
^-- should change to somthing more meaningful to track down the error.
--
(~._.~) Öì Ⱥ Ó¢ (Qun-Ying) (65) 874-6743
( O ) TrustCopy Pte Ltd / Kent Ridge Digital Labs
()~*~() 21 Heng Mui Ken
Richard Levitte - VMS Whacker wrote:
> Hmm, let me get this straight: from what I understand of this
> conversation, tlhelp32.h is needed only to declare things for the heap
> walking code. Is there a way to still be able to do the heap walking
> without having to include tlhelp32.h? If that's a
Jeffrey Altman wrote:
>
>
> Correct. But none of this is needed in this case. If the function
> GetCursorInfo() (for example) is not supported on NT4, then the
> attempt to load its function pointer with
>
> cursor = (GETCURSORINFO) GetProcAddress(user,"GetCursorInfo");
>
> will fail. T
There are some way to determine the running OS, quote from the Win32 FAQ:
5.1.5 How can I tell what version of windows I'm running?
With the function GetVersionEx(). This fills in a structure indicating whether
or not the OS is NT, and what the version number of the OS is
BOOL InWinNT() //tes
Richard Levitte - VMS Whacker wrote:
>
> Relying on compile-time options is not really the best, since binaries
> can be transported between the different Windows variants (and if you
> look at the code, we've definitely made it more and more dynamic in
> that sense).
>
> So, is there a dynami
But it is broken in NT 4.0. The condition I patched in will commented out the
code only for NT version less than 5. It is still included under Win2k and
Win95. And for NT 4 (I am not sure about 3.5), we may properly need to use the
NT only PSAPI to do the similar job.
Jeffrey Altman wrote:
>
> T
I am using VC 6, 0.9.6-beta1 with rand_win.c(version 1.9 from the CVS).
I encounter the following error while building the library:
link /nologo /subsystem:console /machine:I386 /opt:ref /dll /out:out32dl
l\ssleay32.dll /def:ms/SSLEAY32.def @d:\TEMP\nmc00217.
Creating library out32dll\ssleay3
I have checked with mingw32 developers. The reason tlhelp32.h is not in the
distribution because of its win95 only nature. In will never work under NT
4.0(SP6). I don't know whether mingw32 will include that header and lib in
future.
I am using gcc version 2.95.2 19991024 (release) for the built.
Under mingw32:
I managed to by pass the 95 only code, but I don't know how it will affect the
RAND_poll() function, I believe the behaviour changes. I conditionally comment
out the offensive code. (attached is my patch)
The patch is against CVS version 1.9 of the file rand_win.c.
But I encounter
As more information on the mingw32 platform:
The code needed tlhelp32.h is for win95 only not for NT.
the tlhelp32.h is suppose only work in Win95 and later, not in NT at least 4.0.
It is said to to be supported under NT 5.0.
--
(~._.~) Öì Ⱥ Ó¢ (Qun-Ying) (65) 874-6743
( O )
()~*~
tests passed
test a^b%c implementations
./exptest
...
...
done
cat
./p ./p.clear differ: char 2, line 1
35 matches
Mail list logo