Re: connection termiated (LINUX)
Well I tryed to do recogniting of abort connection by select. But it does not help. I try to wait on the third set of select function that may contains the filedescriptors that determines sockets on which is reported some error. But it does not work too. It looks like the socket is ok. Why I thing when I disrupt the conection the certain socket must throw any error. Or am I totaly disinformated? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: connection termiated (LINUX)
Milan Křápek wrote: Well I tryed to do recogniting of abort connection by select. But it does not help. I try to wait on the third set of select function that may contains the filedescriptors that determines sockets on which is reported some error. But it does not work too. It looks like the socket is ok. Why I thing when I disrupt the conection the certain socket must throw any error. Or am I totaly disinformated? How about waiting on the first set of the select() function and watching the error/return code of recv()? -jb -- No snowflake in an avalanche ever feels responsible. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES cbc? How to Init Openssl?
I have some question too. I whould appreciate any help! Why is the initial vector (ivec) needed? I see by reading the openssl code that it is used for xoring with the input before encrypting, but from what I see in other resources, this is not a part of the Rijndael algorithm (It is not the AddRoundKey). So doesn't it make this implementation imcompatible with the standard? (passing ivec of 0 will also not help, since it changes during the function and the changed value is used). Also, I see the code does: const unsigned char *iv = ivec; ... // changing iv while encrypting... and then at the end: memcpy(ivec,iv,AES_BLOCK_SIZE); - For what purpose is the new value of ivec returned to the caller (by the memcpy)? Is there a use for the new ivec after the function returns? Decoding will need the original value, so it can't be for that :/ Thanks to anyone who may explain! -- View this message in context: http://www.nabble.com/AES-cbc--How-to-Init-Openssl--tf4376933.html#a12732509 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES cbc? How to Init Openssl?
Hello, Why is the initial vector (ivec) needed? This is part of CBC mode. This mode does not depend on used block encryption algorithm. Look at: http://en.wikipedia.org/wiki/Cipher_block_chaining As you see, there is no information of AES or DES, this is only mode of operation I see by reading the openssl code that it is used for xoring with the input before encrypting, but from what I see in other resources, this is not a part of the Rijndael algorithm (It is not the AddRoundKey). Yes, this is not part of AES. AES defines one block transformation (16 bytes) in 10, 12, or 14 rounds. At each round, round-key is added by AddRoundKey procedure but this key is only generated from AES key provided by user (128, 192 or 256 bit length) So doesn't it make this implementation imcompatible with the standard? No, there is AES algorithm and block mode operation algorithm. (passing ivec of 0 will also not help, since it changes during the function and the changed value is used). Yes. Also, I see the code does: const unsigned char *iv = ivec; ... // changing iv while encrypting... and then at the end: memcpy(ivec,iv,AES_BLOCK_SIZE); - For what purpose is the new value of ivec returned to the caller (by the memcpy)? Is there a use for the new ivec after the function returns? Decoding will need the original value, so it can't be for that :/ You may want to encrypt some data in chunks and call this functions many times on your data window. For that purpose IV is returned. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES cbc? How to Init Openssl?
Ok, now it's much clearer! Thank you very much, Marek, that helped me a lot. Marek Marcola wrote: Hello, Why is the initial vector (ivec) needed? This is part of CBC mode. This mode does not depend on used block encryption algorithm. Look at: http://en.wikipedia.org/wiki/Cipher_block_chaining As you see, there is no information of AES or DES, this is only mode of operation I see by reading the openssl code that it is used for xoring with the input before encrypting, but from what I see in other resources, this is not a part of the Rijndael algorithm (It is not the AddRoundKey). Yes, this is not part of AES. AES defines one block transformation (16 bytes) in 10, 12, or 14 rounds. At each round, round-key is added by AddRoundKey procedure but this key is only generated from AES key provided by user (128, 192 or 256 bit length) So doesn't it make this implementation imcompatible with the standard? No, there is AES algorithm and block mode operation algorithm. (passing ivec of 0 will also not help, since it changes during the function and the changed value is used). Yes. Also, I see the code does: const unsigned char *iv = ivec; ... // changing iv while encrypting... and then at the end: memcpy(ivec,iv,AES_BLOCK_SIZE); - For what purpose is the new value of ivec returned to the caller (by the memcpy)? Is there a use for the new ivec after the function returns? Decoding will need the original value, so it can't be for that :/ You may want to encrypt some data in chunks and call this functions many times on your data window. For that purpose IV is returned. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AES-cbc--How-to-Init-Openssl--tf4376933.html#a12733779 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Rogue ciphersuite disabled since 0.9.8c
Hi all, working with Apache mod_ssl and different versions of Openssl, I've realized that since version 0.9.8c, the ciphersuites called rogue have been disabled. I've read changelog but I can't understand the reason. I'm interested in using a 56-bit cipher algorithm between my Apache server and the client, because the latter is an small device with no much processor power, so It cant support 128-bit cipher, but It can use 40 or 56 bit cipher. As far as I know, 56 bit cipher is far more dificult to break than 40 bit (actually not very dificult to break I think), so I'd prefer to use 56 bit cipher. Could anybody explain me the reason for disabling 56-bit cipher in Openssl? Does anybody know how could I use a 56-bit cipher working with a recent version of Openssl? I've read something about using TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES directive when configuring and installing Openssl, but I would like to know why this name EXPERIMENTAL, It doesnt make me feel very sure Thanks in advance. (If you think it's not the appropiate mailing-list, please let me know) Sergio Bello
Public encryption and showing certificate to the server
Our server application expects from connecting clients to show their certificate to checks their CN,OU and decide what permissions to allow for that client I generated a client certificate and embedded encrypted private key in it. Everything works. But now I want to avoid using private key of the client to avoid hassle managing private key and storing passwords for it. It seems that public encryption is the way to go. (Sorry, I'm still very confused in terminology) I generated a client certificate without private key in it and do not call anymore following functions which I had before SSL_CTX_set_default_passwd_cb(...); SSL_CTX_use_PrivateKey_file(...); But now SSL_connect fails returning -1 and SSL_get_error doesn't give me a clue. What am I doing wrong? Is it possible to achieve? Thanks, -- View this message in context: http://www.nabble.com/Public-encryption-and-showing-certificate-to-the-server-tf718.html#a12682047 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Public encryption and showing certificate to the server
On Mon, Sep 17, 2007 at 05:43:16AM -0700, avizel wrote: Our server application expects from connecting clients to show their certificate to checks their CN,OU and decide what permissions to allow for that client I generated a client certificate and embedded encrypted private key in it. Everything works. But now I want to avoid using private key of the client to avoid hassle managing private key and storing passwords for it. It seems that public encryption is the way to go. (Sorry, I'm still very confused in terminology) I generated a client certificate without private key in it and do not call anymore following functions which I had before SSL_CTX_set_default_passwd_cb(...); SSL_CTX_use_PrivateKey_file(...); But now SSL_connect fails returning -1 and SSL_get_error doesn't give me a clue. What am I doing wrong? Is it possible to achieve? No, TLS clients don't just present client certs, they sign the handshake with the corresponding private key. It is not possible or useful to accept public key certs without proof that the peer holds the corresponding private key. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl-users] Bad CRL being generated - Help
I have now excluded the issuer from both the end entity cert and the crl. So only keyid is being injected. The result is the same, both IE and FF report an error that the crl is invalid. Here is what I am using in the extensions config file for the crl: [ ca ] default_ca = CA_default # The default ca section [ CA_default ] dir = $dir# Where everything is kept database = $dir/index.txt # database index file. crlnumber = $dir/crlnum unique_subject = no [ crl_ext ] authorityKeyIdentifier=keyid:always Here is what I have in the extensions for the cert: subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always crlDistributionPoints=URI:http://crl1.networksolutions.com/SiteSafeSSL.c rl,URI:http://crl2.networksolutions.com/SiteSafeSSL.crl basicConstraints = critical, CA:false keyUsage=critical, digitalSignature, keyEncipherment extendedKeyUsage=serverAuth, clientAuth nsCertType = server, client certificatePolicies=ia5org,@polsect1 [polsect1] policyIdentifier = 1.3.6.1.4.1.782.1.2.1.19.1 CPS=http://www.networksolutions.com/legal/SSL-legal-repository-cps-SiteS afe.jsp Again here is the URL for the crl and test site: http://crl1.networksolutions.com/SiteSafeSSL.crl http://crl1.networksolutions.com/SiteSafeSSL.crl https://www.netsol-test-site-4.com https://www.netsol-test-site-4.com I am really hoping that I am missing something really simple here. Any help with this would be much appreciated. Regards, Don Donald E. Bynum Director, Architecture Integration O: 703.668.5616 | M: 301.367.2072 | www.networksolutions.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bynum, Don Sent: Saturday, September 15, 2007 3:54 PM To: openssl-users@openssl.org Subject: RE: [openssl-users] Bad CRL being generated - Help That is an interesting and accurate observation. i agree that the issuer and authority should be the same, that I can fix. Another question though: if i had not included the issuer in the cert or in the CRL, i.e. only have the authority keyid present (which are the same in the CRL and the cert) do you think that the problem would still have been there? Regards, Don Bynum Donald E. Bynum Director, Architecture Integration O: 703.668.5616 | M: 301.367.2072 | www.networksolutions.com From: [EMAIL PROTECTED] on behalf of Erwann ABALEA Sent: Sat 9/15/2007 14:37 To: openssl-users@openssl.org Subject: Re: [openssl-users] Bad CRL being generated - Help Bonsoir, Hodie XVII Kal. Oct. MMVII est, Bynum, Don scripsit: i have been setting up a CA and have one hurdle which I cannot figure out. I have geberated a CRL (currently with no revoked certs). It is regerenced in the CRL Distribution Points extension of the end entity certs. I can open the CRL with IE by browsing to the CRL URI. I can import it into Firefox. However, when browsing to a site (IE or FF) with a cert from the CA of the CRL, I get an error saying that the CRL is invalid. You can see this for yourself : [1]http://crl1.networksolutions.com/SiteSafeSSL.crl A test site for this is at [2]https://www.netsol-test-site-4.com https://www.netsol-test-site-4.com/ Taken from the CRL: Issuer: /CN=SiteSafe SSL/O=Network Solutions LLC/C=US CRL extensions: X509v3 Authority Key Identifier: keyid:2A:CB:BC:20:CE:C6:DF:9A:1C:AD:A5:C6:38:86:BB:5C:01:32:A6:B4 DirName:/C=US/O=Network Solutions LLC/CN=SiteSafe serial:0A The Issuer and authorityKeyIdentifier/DirName should point to the same authority, i.e. should have the same exact name. Order is important, and it's reversed, here. I think that usual software don't use the DirName and/or serial part of the authorityKeyIdentifier extension, only the keyId (and in fact, I made some tests a few months ago, Firefox didn't follow the keyId, when IE did). So I assume that the validating software uses the Issuer field of the CRL to check if it has been signed by the same CA. My guess is that the real name of your CA is the one we can see in the extension, not the one set in the Issuer field. Could you check it? -- Erwann ABALEA [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org http://www.openssl.org/ User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] netsollogo.gif
Re: Rogue ciphersuite disabled since 0.9.8c
On Mon, Sep 17, 2007, Besbello wrote: Hi all, working with Apache mod_ssl and different versions of Openssl, I've realized that since version 0.9.8c, the ciphersuites called rogue have been disabled. I've read changelog but I can't understand the reason. I'm interested in using a 56-bit cipher algorithm between my Apache server and the client, because the latter is an small device with no much processor power, so It cant support 128-bit cipher, but It can use 40 or 56 bit cipher. There isn't a direct correlation between symmetric key size and processing power required. Indeed in some cases the actual key size indicates the entropy used as opposed to the physical key size: so a 40 bit key may actually be a 128 bit key with 40 bits of entropy and you wouldn't notice any difference in speed. I'd suggest you do some tests to see what performance difference (if any) is present when using 128 bit keys. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Public encryption and showing certificate to the server
Our server application expects from connecting clients to show their certificate to checks their CN,OU and decide what permissions to allow for that client I generated a client certificate and embedded encrypted private key in it. Everything works. Gret. But now I want to avoid using private key of the client to avoid hassle managing private key and storing passwords for it. It seems that public encryption is the way to go. (Sorry, I'm still very confused in terminology) How would that possibly work? If there is nothing that the client knows that nobody else knows, how do you expect it to prove its identity? Public encryption means the *server* does not need the client's private key to verify that the client knows the private key. If the client doesn't know its own private key, the certificate does no good. I generated a client certificate without private key in it and do not call anymore following functions which I had before SSL_CTX_set_default_passwd_cb(...); SSL_CTX_use_PrivateKey_file(...); But now SSL_connect fails returning -1 and SSL_get_error doesn't give me a clue. What am I doing wrong? Is it possible to achieve? If the client does not have the private key corresponding to the public key in the certificate, how can it prove the certificate is for it rather than someone else? How do you imagine this is supposed to work? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
0.9.8e: SIGILL in test tx509 (I have read the FAQ)
Hello, I'm running make test on openssl-0.9.8e built under linux and getting an illegal instruction in the tx509 test, both with and without the no-sse2 build option: $ bash -x ./tx509 + cmd='../util/shlib_wrap.sh ../apps/openssl x509' + '[' x '!=' x ']' + t=testx509.pem + echo testing X509 conversions testing X509 conversions + cp testx509.pem fff.p + echo 'p - d' p - d + ../util/shlib_wrap.sh ../apps/openssl x509 -in fff.p -inform p -outform d ./tx509: line 15: 26320 Illegal instruction $cmd -in fff.p -inform p -outform d f.d + '[' 132 '!=' 0 ']' + exit 1 My CPU has these flags: $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 44 model name : AMD Sempron(tm) Processor 3000+ stepping: 2 cpu MHz : 1808.372 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts fid vid ttp tm stc bogomips: 3620.08 clflush size: 64 My build configure line is: ./Configure no-idea no-rc5 enable-camellia shared linux-elf Any hints? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
