[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

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

[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

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

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

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

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

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:

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:

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

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.

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

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

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)

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

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

'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