[openssl.org #1603] OpenSSL and Visual Studio 2005/VC8
Hi All, I am currently migrating all my sources to VC8, as VC6 is not supported anymore (end of life support). Do you have already a version of Openssl sources supported by MS VC8 ? If not, when do foreseen it to be avalaible. Thanks in advance ___ Benoît Lejeune Manager ___ Group System Engineering Euroclear SA Bld du Roi Albert II, 1 B - 1210 Brussels Tel: +32 (0)2 224 2329 Fax: +32 (0)2 789 5712 Email : [EMAIL PROTECTED] ___ This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient you should not read, copy, distribute, disclose or otherwise use this information. If you have received this message in error, please notify us immediately and delete it from your system. The integrity and security of this message cannot be guaranteed and it may be subject to data corruption and unauthorised amendment, for which we accept no liability. Euroclear reserves the right to retain email messages on its systems and to the extent and under circumstances permitted by applicable law, to monitor and intercept email messages to and from its systems. Euroclear is the marketing name for the Euroclear System, Euroclear plc, Euroclear SA/NV and their affiliates. Please visit our website: http://www.euroclear.com Hi All, I am currently migrating all my sources to VC8, as VC6 is not supported anymore (end of life support). Do you have already a version of Openssl sources supported by MS VC8 ? If not, when do foreseen it to be avalaible. Thanks in advance ___ Benoît Lejeune Manager ___ Group System Engineering Euroclear SA Bld du Roi Albert II, 1 B - 1210 Brussels Tel: +32 (0)2 224 2329 Fax: +32 (0)2 789 5712 Email : [EMAIL PROTECTED] ___ This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient you should not read, copy, distribute, disclose or otherwise use this information. If you have received this message in error, please notify us immediately and delete it from your system. The integrity and security of this message cannot be guaranteed and it may be subject to data corruption and unauthorised amendment, for which we accept no liability. Euroclear reserves the right to retain email messages on its systems and to the extent and under circumstances permitted by applicable law, to monitor and intercept email messages to and from its systems. Euroclear is the marketing name for the Euroclear System, Euroclear plc, Euroclear SA/NV and their affiliates. Please visit our website: http://www.euroclear.com
Re: [openssl.org #1602] X509_new, X509_free do not appear in any headers
Hi, 2007/11/13, Jacques Vidrine via RT [EMAIL PROTECTED]: The functions X509_new and X509_free are documented in doc/crypto/ X509_new.pod, but they do not appear in any headers. They are declared by DECLARE_ASN1_FUNCTIONS(X509) in x509.h, lign 930. This macro is defined in asn1.h lign 287 to 319. Regards, -- Jean Rebiffe __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] dependant - dependent in documentation
Hi, I just noticed that most occurences of dependant have been fixed since 0.9.7, but it seems that some have slipped through or were added afterwards. diff -ur openssl-orig/doc/crypto/DH_set_method.pod openssl-work/doc/crypto/DH_set_method.pod --- openssl-orig/doc/crypto/DH_set_method.pod Fri Nov 9 19:09:56 2007 +++ openssl-work/doc/crypto/DH_set_method.pod Fri Nov 9 19:10:45 2007 @@ -36,7 +36,7 @@ as a default for DH, so this function is no longer recommended. DH_get_default_method() returns a pointer to the current default DH_METHOD. -However, the meaningfulness of this result is dependant on whether the ENGINE +However, the meaningfulness of this result is dependent on whether the ENGINE API is being used, so this function is no longer recommended. DH_set_method() selects Bmeth to perform all operations using the key Bdh. diff -ur openssl-orig/doc/crypto/DSA_set_method.pod openssl-work/doc/crypto/DSA_set_method.pod --- openssl-orig/doc/crypto/DSA_set_method.pod Fri Nov 9 19:09:56 2007 +++ openssl-work/doc/crypto/DSA_set_method.pod Fri Nov 9 19:10:49 2007 @@ -36,7 +36,7 @@ been set as a default for DSA, so this function is no longer recommended. DSA_get_default_method() returns a pointer to the current default -DSA_METHOD. However, the meaningfulness of this result is dependant on +DSA_METHOD. However, the meaningfulness of this result is dependent on whether the ENGINE API is being used, so this function is no longer recommended. diff -ur openssl-orig/doc/crypto/RAND_set_rand_method.pod openssl-work/doc/crypto/RAND_set_rand_method.pod --- openssl-orig/doc/crypto/RAND_set_rand_method.podFri Nov 9 19:09:56 2007 +++ openssl-work/doc/crypto/RAND_set_rand_method.podFri Nov 9 19:10:53 2007 @@ -30,7 +30,7 @@ is no longer recommended. RAND_get_default_method() returns a pointer to the current RAND_METHOD. -However, the meaningfulness of this result is dependant on whether the ENGINE +However, the meaningfulness of this result is dependent on whether the ENGINE API is being used, so this function is no longer recommended. =head1 THE RAND_METHOD STRUCTURE diff -ur openssl-orig/doc/crypto/RSA_set_method.pod openssl-work/doc/crypto/RSA_set_method.pod --- openssl-orig/doc/crypto/RSA_set_method.pod Fri Nov 9 19:09:56 2007 +++ openssl-work/doc/crypto/RSA_set_method.pod Fri Nov 9 19:10:56 2007 @@ -42,7 +42,7 @@ been set as a default for RSA, so this function is no longer recommended. RSA_get_default_method() returns a pointer to the current default -RSA_METHOD. However, the meaningfulness of this result is dependant on +RSA_METHOD. However, the meaningfulness of this result is dependent on whether the ENGINE API is being used, so this function is no longer recommended. diff -ur openssl-orig/doc/crypto/engine.pod openssl-work/doc/crypto/engine.pod --- openssl-orig/doc/crypto/engine.pod Fri Nov 9 19:09:56 2007 +++ openssl-work/doc/crypto/engine.pod Fri Nov 9 19:11:04 2007 @@ -183,7 +183,7 @@ treated as handles - ie. not only as pointers, but also as references to the underlying ENGINE object. Ie. one should obtain a new reference when making copies of an ENGINE pointer if the copies will be used (and -released) independantly. +released) independently. ENGINE objects have two levels of reference-counting to match the way in which the objects are used. At the most basic level, each ENGINE pointer is @@ -200,7 +200,7 @@ specialised form of structural reference, because each functional reference implicitly contains a structural reference as well - however to avoid difficult-to-find programming bugs, it is recommended to treat the two -kinds of reference independantly. If you have a functional reference to an +kinds of reference independently. If you have a functional reference to an ENGINE, you have a guarantee that the ENGINE has been initialised ready to perform cryptographic operations and will remain uninitialised until after you have released your reference. @@ -587,7 +587,7 @@ The ENGINE API and internal architecture is currently being reviewed. Slated for possible release in 0.9.8 is support for transparent loading of dynamic ENGINEs (built as self-contained shared-libraries). This would allow ENGINE -implementations to be provided independantly of OpenSSL libraries and/or +implementations to be provided independently of OpenSSL libraries and/or OpenSSL-based applications, and would also remove any requirement for applications to explicitly use the dynamic ENGINE to bind to shared-library implementations. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
i have a trouble in openssl
hi all:
first thanks for your openssl.
i use the openssl0.9.8g ＋ DTLS patch。i found a bug in my code.
there is the information:
I have an issue in OpenSSL, I call the free function to free the BIO resource:
if (para.dtls.SslBioPtr != NULL){ çI do the test, the free
point is the correct address which get from BIO_new_dgram
ah_err(ready free BIO %x,para.dtls.SslBioPtr);
BIO_free(para.dtls.SslBioPtr); =core after this function
ah_err(free BIO ok); çcan not print this
information
para.dtls.SslBioPtr = NULL;
}
I often found core after BIO_free function. But I add the debug
information to BIO_free function, each time the function is return correct. But
the next information is not print out (free BIO ok), segment fault will happen.
I check the core file, every time core is in libc function:
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x0f9a5088 in main_arena () from
/opt/aero/crosstool/gcc-4.0.3-glibc-2.3.5/powerpc-603-linux-gnu/powerpc-603-linux-gnu/lib/libc.so.6
(gdb) bt
#0 0x0f9a5088 in main_arena () from
/opt/aero/crosstool/gcc-4.0.3-glibc-2.3.5/powerpc-603-linux-gnu/powerpc-603-linux-gnu/lib/libc.so.6
#1 0x0fa602a4 in file_ctrl () from
/opt/aero/crosstool/gcc-4.0.3-glibc-2.3.5/powerpc-603-linux-gnu/powerpc-603-linux-gnu/lib/libcrypto.so.0.9.8
#2 0x10015054 in dtls_clean () at dtls.c:90
#3 0x1001560c in dtls_thread () at dtls.c:217
#4 0x0fe04f48 in pthread_start_thread () from
/opt/aero/crosstool/gcc-4.0.3-glibc-2.3.5/powerpc-603-linux-gnu/powerpc-603-linux-gnu/lib/libpthread.so.0
#5 0x0f9316f8 in clone () from
/opt/aero/crosstool/gcc-4.0.3-glibc-2.3.5/powerpc-603-linux-gnu/powerpc-603-linux-gnu/lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I google the main_arena function, there have many segment fault in this
function. But I don’t found the file_ctrl function with main_arena,
Is it our libc problem? Can you help me?
thanks
lei
Re: make SSL_shutdown work with non-blocking BIOs
On Mon, Oct 01, 2007 at 08:06:04PM +0100, Darryl Miles wrote: Would Davide be so kind as to look over the following openssl-dev list post for the semantics I suggest and confirm that logic would work for him: http://marc.info/?l=openssl-devm=115153998821797w=2 The archive at marc.info seems to have stripped the patches off this message. Are your patches for ssl_shutdown() available somewhere I could have another look at them? Thanks! Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
aes-128-cfb1 bug
Hi developers, I find a bug of aes-128-cfb1: If key is 2b7e151628aed2a6abf7158809cf4f3c , iv is 000102030405060708090a0b0c0d0e0f, plain-text is a or abc, aes-128-cfb1 can not encrypt/decrypt correctly. The following is the log file. We can see that decryption result is different from original plain-text. [EMAIL PROTECTED] uname -allHP-UX sshia1 B.11.23 U ia64 3432702471 unlimited-user [EMAIL PROTECTED] openssl versionOpenSSL 0.9.7m 23 Feb [EMAIL PROTECTED] echo a\c [EMAIL PROTECTED] cat [EMAIL PROTECTED] od -x filea000 [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -in filea -out filea.enc.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -d -in filea.enc.97m -out filea.dec.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv [EMAIL PROTECTED] cat [EMAIL PROTECTED] od -x filea.dec.97m000[EMAIL PROTECTED]@sshia1# echo abc\c [EMAIL PROTECTED] cat [EMAIL PROTECTED] od -x fileabc000 6162[EMAIL PROTECTED] openssl enc -aes-128-cfb1 -in fileabc -out fileabc.enc.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -d -in fileabc.enc.97m -out fileabc.dec.97m \ -K 2b 7e151628aed2a6abf7158809cf4f3c -iv [EMAIL PROTECTED] cat [EMAIL PROTECTED] od -x fileabc.dec.97m000 606f[EMAIL PROTECTED] The bug at least exists in openssl-0.9.7m, openssl-0.9.7l and openssl-0.9.8b.I do the test on following platform:openssl-0.9.7m + HP-UX 11.23 + Itanium CPUopenssl-0.9.7m + HP-UX 11.23 + PA-RISC CPUopenssl-0.9.7l + HP-UX 11.11 + PA-RISC CPUopenssl-0.9.8b + Redhat Enterprise Linux 5 + x86 CPU Would you please study this bug? Best RegardsYiqun Ren _ Windows Live Custom Domain，您的免费电子邮局。 https://domains.live.com/default.aspx
adaptation licensing
Hi list, I derived a file from ssl_rsa.c which is found in the openssl distribution and included it in a project of mine. Since then the content has evolved as you can tell here: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/hoststated/ssl_privsep.c I wonder if I should still keep the original OpenSSL license or if its ok to relicense it under the ISC (used throughout OpenBSD) license. I can't reach eric young unfortunately, hence I'm asking here. Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1565] [PATCH] New port for the iSeries (AS/400) for version 0.9.8e
Hi, They are not in the tree. They are supplied in the tgz that includes the patch, for installation in your own development environment, in the location of your preference. G. -Original Message- From: Ronald Ojakian via RT [mailto:[EMAIL PROTECTED] Sent: 12 November 2007 22:44 To: Shaw Graham George Cc: openssl-dev@openssl.org Subject: [openssl.org #1565] [PATCH] New port for the iSeries (AS/400) for version 0.9.8e Applied AS400.patch to openssl 0.9.8e Need to know location of script files in the tree: cvtascii.sh cvtcnfebcdic.sh cvtpemascii.sh cvtcnfascii.sh cvtebcdic.sh cvtpemebcdic.sh Can you point me to a complete OS400 0.9.8e openssl source tree? Thanks Ronald Ojakian Ingrian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1565] [PATCH] New port for the iSeries (AS/400) for version 0.9.8e
Hi, They are not in the tree. They are supplied in the tgz that includes the patch, for installation in your own development environment, in the location of your preference. G. -Original Message- From: Ronald Ojakian via RT [mailto:[EMAIL PROTECTED] Sent: 12 November 2007 22:44 To: Shaw Graham George Cc: openssl-dev@openssl.org Subject: [openssl.org #1565] [PATCH] New port for the iSeries (AS/400) for version 0.9.8e Applied AS400.patch to openssl 0.9.8e Need to know location of script files in the tree: cvtascii.sh cvtcnfebcdic.sh cvtpemascii.sh cvtcnfascii.sh cvtebcdic.sh cvtpemebcdic.sh Can you point me to a complete OS400 0.9.8e openssl source tree? Thanks Ronald Ojakian Ingrian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: aes-128-cfb1 bug
It's a length thing. CFB1 expects the length in bits, not bytes. If you multiply the length by 8 inside crypto/aes/aes_cfb.c AES_cfb1_encrypt, it works fine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RenYiqun Sent: Tuesday, November 13, 2007 7:01 AM To: openssl-dev@openssl.org Subject: aes-128-cfb1 bug Hi developers, I find a bug of aes-128-cfb1: If key is 2b7e151628aed2a6abf7158809cf4f3c , iv is 000102030405060708090a0b0c0d0e0f, plain-text is a or abc, aes-128-cfb1 can not encrypt/decrypt correctly. The following is the log file. We can see that decryption result is different from original plain-text. [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# uname -all HP-UX sshia1 B.11.23 U ia64 3432702471 unlimited-user license [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# openssl version OpenSSL 0.9.7m 23 Feb 2007 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# echo a\c filea [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# cat filea [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# od -x filea 000 6100 001 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# openssl enc -aes-128-cfb1 -in filea -out filea.enc.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED]mailto%20:[EMAIL PROTECTED]# openssl enc -aes-128-cfb1 -d -in filea.enc.97m -out filea.dec.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# cat filea.dec.97m [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# od -x filea.dec.97m 0000 001 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# echo abc\c fileabc [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# cat fileabc [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# od -x fileabc 000 61626300 003 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# openssl enc -aes-128-cfb1 -in fileabc -out fileabc.enc.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# openssl enc -aes-128-cfb1 -d -in fileabc.enc.97m -out fileabc.dec.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# cat fileabc.dec.97m [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]# od -x fileabc.dec.97m 000 606f6e00 003 [EMAIL PROTECTED] a1mailto:[EMAIL PROTECTED]# The bug at least exists in openssl-0.9.7m, openssl-0.9.7l and openssl-0.9.8b. I do the test on following platform: openssl-0.9.7m + HP-UX 11.23 + Itanium CPU openssl-0.9.7m + HP-UX 11.23 + PA-RISC CPU openssl-0.9.7l + HP-UX 11.11 + PA-RISC CPU openssl-0.9.8b + Redhat Enterprise Linux 5 + x86 CPU Would you please study this bug? Best Regards Yiqun Ren 使用新一代 Windows Live Messenger 轻松交流和共享！ 立即体验！http://messenger.live.cn/
TLS extension - howto (long)
Hi dev,
I'm experimenting a little with TLS extensions... I managed to exchange
an extension between the client and the server, but I have few
questions.
First of all, must I write all the code for extension handling for each
new extension or is there any common way to handle generic extension.
I figured there was no such method, so I add all the code to handle my
extension.
I wrote a mini howto (attached here below); is there anyone who can
confirm me if it's the right way for adding my own extensions to
OpenSSL?
Are the extensions stores in the form of TLV? If yes, should I use the
functions s2n() and n2s() to write and read the values?
Many many thanks to anyone who will answer any of my questions.
- Here starts the mini howto -
Adding an extension to OpenSSL
--== 0 ==-- Requirements
OpenSSL 0.9.9
--== 1 ==-- Define the new extension
Edit the file ssl/tls1.h and define the extension type:
#define TLSEXT_TYPE_DV_myTest 46 /* 46 is by random...
any free number should go
See RFC 4366 for more
information */
Edit the file ssl/ssl.h and add new elements to ssl_st:
size_t tlsext_DV_myTest_length; /* Length of the extension */
unsigned char * tlsext_DV_myTest; /* Out new extension.
Later on it should be
allocated of size
tlsext_DV_myTest_length */
--== 2 ==-- Prepare che extension
Edit the file ssl/t1_lib.c and modify the function
int ssl_prepare_clienthello_tlsext
this function prepares the client hello. This should happend on the
client.
(...)
if (s-version == TLS1_VERSION) { /* We just test if we're
using TLS... otherwise
there should be no
extension.
It is possible that this
test is done somewhere
else into OpenSSL,
but I don't know. */
fprintf (stderr, Preparing the extension to add to \
the client hello\n);
/* We allocate of the memory for the extension */
if ((s-tlsext_DV_myTest = OPENSSL_malloc(2)) == NULL) {
SSLerr(SSL_F_SSL_PREPARE_CLIENTHELLO_TLSEXT,
ERR_R_MALLOC_FAILURE);
return -1;
}
/* We set the size of the extension */
s-tlsext_DV_myTest_length = 2;
/* We put some test data into the extension */
s-tlsext_DV_myTest[0] = 0;
s-tlsext_DV_myTest[1] = 1;
}
(...)
In the same file modify the function
unsigned char *ssl_add_clienthello_tlsext
this function add the extensions to the client hello. This should happen
on the client.
(...)
/* Add this to the end of the function... see below */
if (s-tlsext_DV_test_ext != NULL) {
/* Add our TLS extension to the ClientHello message */
long lenmax; /* Max length of our extension */
/* Check for enough space...
lenmax must be limit - ret - 4
1: type
1: lenght
2: extension
Not still sure if 4 must be hard coded or not...
*/
if ((lenmax = limit - ret - 4) 0)
return NULL;
/* Not enough space for the extension */
/* We add the type of the extension to the client hello */
s2n(TLSEXT_TYPE_DV_myTest, ret);
/* We add the length of the extension to the client hello */
s2n(s-tlsext_DV_myTest_length,ret);
/* We copy the value of the extension in place */
memcpy(ret, s-tlsext_DV_myTest,
s-tlsext_DV_myTest_length);
/* We move forward ret so next extensions have space */
ret+=s-tlsext_DV_myTest_length;
}
/* From now on is OpenSSL code. Do not modify */
if ((extdatalen = ret-p-2)== 0) {
printf (DV: (extdatalen = ret-p-2)== 0\n);
return p;
}
s2n(extdatalen,p);
return ret;
}
--== 3 ==-- Handle the extension on the server
DTLS close alert processing in 0.9.8g
While testing interop of our DTLS implementation with openssl 0.9.8g I
found an issue with openssl client handling the close notify alert from
our server.
After our server responds to the GET / it sends a close notify alert to
close the connection.
openssl gets the alert and decrypts it correctly but doesn't process the
alert and enters a state where it is waiting for another record from the
server.
The problem appears to be in the following code in dtls1_read_bytes() in
d1_pkt.c
if (dest_maxlen 0)
{
/* XDTLS: In a pathalogical case, the Client Hello
* may be fragmented--don't always expect dest_maxlen bytes
*/
if ( rr-length dest_maxlen )
{
s-rstate=SSL_ST_READ_HEADER;
rr-length = 0;
goto start;
}
/* now move 'n' bytes: */
for ( k = 0; k dest_maxlen; k++)
{
dest[k] = rr-data[rr-off++];
rr-length--;
}
*dest_len = dest_maxlen;
}
}
In my case before if (dest_maxlen 0) I have dest_max_len = 7 and
rr_length = 2.
The if ( rr-length dest_maxlen ) causes a goto start where another
call to
dtls1_get_record() will take place, which is incorrect because the alert
has not been handled.
I am not sure what is the purpose of the if ( rr-length dest_maxlen )
I can force the code to handle the alert if I if change the code to this:
if ( rr-length dest_maxlen (rr-type != SSL3_RT_ALERT))
This is just my own hack and may not be the correct action.
---
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [EMAIL PROTECTED]
PHONE: (905) 501-3848
FAX : (905) 507-4230
WEBSITE: www.certicom.com
RE: aes-128-cfb1 bug
Yes, cfb1 is just plain ugly. Because the EVP layer expects bytes, but cfb1 (by design) expects bits it gets really nasty. I did manage to get cfb1 to pass the NIST AES test suite, but only by messing with the data at input and output - and even then I doubt that it's really working properly via the EVp layer. It won't just be AES cfb1 that has issues here, DES and Camellia have the same problems. Peter From: Yair Elharrar [EMAIL PROTECTED] To: 'openssl-dev@openssl.org' openssl-dev@openssl.org Date: 14/11/2007 01:30 Subject:RE: aes-128-cfb1 bug It's a length thing. CFB1 expects the length in bits, not bytes. If you multiply the length by 8 inside crypto/aes/aes_cfb.c AES_cfb1_encrypt, it works fine. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] On Behalf Of RenYiqun Sent: Tuesday, November 13, 2007 7:01 AM To: openssl-dev@openssl.org Subject: aes-128-cfb1 bug Hi developers, I find a bug of aes-128-cfb1: If key is 2b7e151628aed2a6abf7158809cf4f3c , iv is 000102030405060708090a0b0c0d0e0f, plain-text is a or abc, aes-128-cfb1 can not encrypt/decrypt correctly. The following is the log file. We can see that decryption result is different from original plain-text. [EMAIL PROTECTED] uname -all HP-UX sshia1 B.11.23 U ia64 3432702471 unlimited-user license [EMAIL PROTECTED] openssl version OpenSSL 0.9.7m 23 Feb 2007 [EMAIL PROTECTED] echo a\c filea [EMAIL PROTECTED] cat filea [EMAIL PROTECTED] od -x filea 000 6100 001 [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -in filea -out filea.enc.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -d -in filea.enc.97m -out filea.dec.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED] cat filea.dec.97m [EMAIL PROTECTED] od -x filea.dec.97m 0000 001 [EMAIL PROTECTED] [EMAIL PROTECTED] echo abc\c fileabc [EMAIL PROTECTED] cat fileabc [EMAIL PROTECTED] od -x fileabc 000 61626300 003 [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -in fileabc -out fileabc.enc.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED] openssl enc -aes-128-cfb1 -d -in fileabc.enc.97m -out fileabc.dec.97m \ -K 2b7e151628aed2a6abf7158809cf4f3c -iv 000102030405060708090a0b0c0d0e0f [EMAIL PROTECTED] cat fileabc.dec.97m [EMAIL PROTECTED] od -x fileabc.dec.97m 000 606f6e00 003 [EMAIL PROTECTED] a1# The bug at least exists in openssl-0.9.7m, openssl-0.9.7l and openssl-0.9.8b. I do the test on following platform: openssl-0.9.7m + HP-UX 11.23 + Itanium CPU openssl-0.9.7m + HP-UX 11.23 + PA-RISC CPU openssl-0.9.7l + HP-UX 11.11 + PA-RISC CPU openssl-0.9.8b + Redhat Enterprise Linux 5 + x86 CPU Would you please study this bug? Best Regards Yiqun Ren 使用新一代 Windows Live Messenger 轻松交流和共享！ 立即体验！
Loophole in Windows RNG
This paper justifies the decision not to rely on the Windows Random Number Generator. http://eprint.iacr.org/2007/419.pdf Quoting: We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in O(223) work (this is an attack on the forward-security of the generator, an O(1) attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks. The generator is run in user mode rather than in kernel mode, and therefore it is easy to access its state even without administrator privileges. The implication of these findings is that a buffer overflow attack or a similar attack can be used to learn a single state of the generator, which can then be used to predict all random values, such as SSL keys, used by a process in all its past and future operation. This attack is more severe and more efficient than known attacks, in which an attacker can only learn SSL keys if it is controlling the attacked machine at the time the keys are used. smime.p7s Description: S/MIME Cryptographic Signature
Re: Loophole in Windows RNG
yeah, I keep hearing about this. Some questions come to mind... wasn't one of these MS RNG's tested via FIPS at some point? what's the logic in concluding Win2k and WinXP and Vista have different RNG's? is this really the end of the world? I mean, is there some specific attack? is there a proof-of-concept code snippet that breaks (ssl, ipsec, smime, code signing, ...) something in windows? why, if win2k is essentially end-of-life, would they not check windows xp? this makes me question their methodology. Jeffrey Altman wrote: This paper justifies the decision not to rely on the Windows Random Number Generator. http://eprint.iacr.org/2007/419.pdf __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Loophole in Windows RNG
On Tue, Nov 13, 2007 at 03:37:42PM -0800, Rodney Thayer wrote: wasn't one of these MS RNG's tested via FIPS at some point? This seems likely. FIPS 140-2 cert #103 seems like the relevant cert http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2000.htm#103 Further, the pseudocode outlined by the authors looks to me as if it's a really botched attempt (attempted enhancement?) of a FIPS 186-2 Appendix 3.1 RNG (though, the authors of the paper didn't think so). If this is indeed in the validated module, the lab doing the evaluation missed it. When this particular evaluation occurred, there was no requirement for algorithm testing for the RNG. You'll also note that there was also no requirement for algorithm testing the RNG for the Windows XP CAPI providers, so the design of those RNGs are also anyone's guess. Some more recent CAPI providers have algorithm certs, so this flaw presumably does not exist in all versions of the CryptGenRandom RNG: certs #321, #316, #314, #313, #292, #286, and #66) http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngval.html (these cover some WinCE providers, Windows server 2003, and the Windows Vista RNG implementation) why, if win2k is essentially end-of-life, would they not check windows xp? this makes me question their methodology. Their style of evaluation suggests that they reverse engineered the relevant components, which takes a fair bit of time. They may have looked at newer versions and noted that they were different and just not put the time into the analysis. It could also be that they want to be able to publish another paper later. :-) Josh __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
'make test' fails w/openssl 0.9.8g on SCO OSR507
openssl 0.9.8g SCO Openserver 5.0.7 'make test' when building openssl 0.9.8g on SCO Openserver 507 using either cc or gcc, produces this error: NIST curve P-521 -- Generator: x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14 B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66 y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97 EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650 verify degree ... ok verify group order ok combined multiplication .ectest.c:713: ABORT 25843:error:1008F044:elliptic curve routines:COMPUTE_WNAF:internal error:ec_mult .c:219: make[1]: *** [test_ec] Error 1 There is this notation in the 0.9.8e-0.9.8f section of CHANGES: *) Fix crypto/ec/ec_mult.c to work properly with scalars of value 0 (which previously caused an internal error). [Bodo Moeller] Last version I tried building was 0.9.8e which was successful. -- Roger Cornelius[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
