Re: [openssl-users] upgrade system's OpenSSL and libs on Mac OS X 10.6.8
On 11 mai 2015, at 07:43, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Mon, May 11, 2015 at 07:07:13AM +0200, Patrick Proniewski wrote: I would like to upgrade openssl, libssl and libcrypto on my Mac OS X 10.6.8 system. The purpose is to allow system and softwares to use the new libs (for example ssh, sshd, Mail...). Do you think it's possible? You can install OpenSSL from MacPorts or Homebrew, choose whichever you prefer. Using MacPorts/Homebrew instead of manual install would allow /usr/bin/ssh (for example) to use /usr/local/openssl/lib/libcrypto.1.0.0.dylib instead of /usr/lib/libcrypto.0.9.8.dylib ? I can already install openssl and libs somewhere else (/usr/local), but if possible I would like to replace those provided by the system. That would be a mistake. It is best to not replace system libraries with incompatible upstream versions. how much do you think it would be incompatible? The more I think about it, the more I do agree with you, but I can't help thinking that's too bad I can't upgrade openssl+libs on my system. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] x509_config nameConstraints
Hi, I read the OpenSSL Cookbook by Ivan Ristic and saw how he configured nameConstraints so I adapted it for my setup. First I tried the following but that doesn't work. permitted;DNS.0=lan permitted;DNS.1=local permitted;IP.0=10.0.0.0/255.0.0.0 permitted;IP.1=172.16.0.0/255.240.0.0 permitted;IP.2=192.168.0.0/255.255.0.0 excluded;IP.3=0.0.0.0/0.0.0.0 excluded;IP.4=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 Then I thought maybe reordering might help like excluded;IP.0=0.0.0.0/0.0.0.0 excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 permitted;DNS.0=lan permitted;DNS.1=local permitted;IP.2=10.0.0.0/255.0.0.0 permitted;IP.3=172.16.0.0/255.240.0.0 permitted;IP.4=192.168.0.0/255.255.0.0 but that gives the same result except that the ordering is different. So I guess as soon as one permitted entry is specified everything else is automatically excluded (vice-versa for excluded / permitted). If that's the case the following configuration should only allow certificates for any domain name using the TLDs lan or local and for any IP address of one of the three private networks but everything else will draw the certificate invalid. Is that correct? permitted;DNS.0=lan permitted;DNS.1=local permitted;IP.0=10.0.0.0/255.0.0.0 permitted;IP.1=172.16.0.0/255.240.0.0 permitted;IP.2=192.168.0.0/255.255.0.0 If my assumption is correct, why does the CA/Browser Forum’s Baseline Requirements define this? Do I have to do so because there's a bug (somewhere) that permits certificates for IP addresses just because DNS is permitted? Would I also have to exlcude email, URI, RID, dirName and / or othername too? Thank you very much in advance! Best regards, Ben ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] compared performances on Mac OS X 10.6.8
On 11 mai 2015, at 07:45, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Mon, May 11, 2015 at 07:24:10AM +0200, Patrick Proniewski wrote: I've compiled OpenSSL 1.0.2a on Mac OS X 10.6.8, and used `openssl speed` to compare performances with stock OpenSSL (0.9.8). In many tests, 1.0.2a is a bit faster, or as fast as 0.9.8y, but on the 6 AES tests, the old one is almost twice as fast as the new one: Use openssl speed -evp. Then if your hardware has AES-NI, it will be faster in 1.0.2. Otherwise, the slowdown is expected. The software-only AES in 1.0.x is constant-time, and avoids timing side-channel attacks. The 0.9.8 version is not constant time (faster, but less secure). Thank you for this explanation. The evp flag works great on my hardware: $ apps/openssl speed -evp aes-256-cbc ../.. aes-256-cbc 171795.47k 200081.86k 208523.35k 211620.52k 210927.62k $ apps/openssl speed aes-256-cbc ../.. aes-256 cbc 68905.90k73930.92k75199.15k75868.16k76136.45k regards, patpro ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Stand alone AES-CTR module
While implementing one's own security and/or cryptography is certainly not advisable for a novice (or even advanced programmers), creating cipher implementations from scratch is probably one of the best ways to learn and understand the intricacies of the problem at hand. Learning about the pitfalls and advantages of the algorithms is key for a future security expert. Moreover, denying someone access to help on an open source project is antithetical to the OSS philosophy. How can anyone hope to understand code that by its very nature is cryptic and complex if there's no one willing to help disentangle, at least at a high level, the routines and functions? InfoSec is a black art today, but it needs to get out of that mode. After the last few years it is clear that unless we open up the understanding of these disciplines, we will be at the mercy of experts with hidden agendas. Only educated users can hope to make correct use of cryptography, or be able to choose the best application for their needs. As we know, even a robust cipher is useless if utilized for the wrong purpose or poorly configured. We can't turn away those with a genuine interest in learning how to use cryptography without dooming ourselves to continue with the status quo. I appeal to those of you who routinely share your knowledge and try to make a difference here, that you provide some guidance and not turn away people with basic questions like this one. These are the users who may become one day contributors. They should be nurtured and not shunned. OK, I'll get off my soapbox now. Have a great week everyone. On May 10, 2015, at 5:58 PM, Mike Mohr akih...@gmail.com wrote: The task of implementing AES should not be undertaken by a novice programmer. Please save the world another heartbleed and pick something more in line with your skill level. On May 10, 2015 11:48 AM, konstantinos Alexiou konstantinako...@gmail.com wrote: Dear Sirs, I am new to C programming and i am trying to create an independent to libraries source code for demonstration purposes for AES-CTR mode.Could i have some help on doing that using the source code contained under crypto/aes. Thank you very much in advance. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Mon, May 11, 2015 at 04:42:49PM +, Viktor Dukhovni wrote: On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject[*] TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. [*] Except when employing unauthenticated encrypted communication to mitigate passive monitoring (oportunistic security). As this would be replacing RFC2712, it's not opportunistic to begin with :) ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Stand alone AES-CTR module
If you don't know about list comprehension in Python, you can simply construct a list in a loop to get the job done. The end result is the same no matter which approach you take. The same is not true for cryptography. While Sec_Aficionado is quite eloquent and makes several valid points, I think his overall argument does not hold water. I have audited the crypto implementations in a number of open-source projects over the years found wide variance in their quality. In one instance a popular piece of software included a feature which claimed to encrypt its data using AES-256. It turned out that the code copied the user's password directly into the key buffer, either padding with null bytes or truncating depending on the length. The data was then encrypted using AES-256 in ECB mode. The software's primary purpose was not cryptography, and it provided innovative and creative features otherwise. This type of bug is insidious, since it doesn't really protect the data in any meaningful way and lulls its users into a false sense of security. I am not advocating that the realm of information security be forever relegated to a select few. That is also dangerous, as Sec_Aficionado correctly pointed out. However, the study of cryptography should never be undertaken without the guidance of an experienced practitioner. I had the extraordinary opportunity to study information security at university under the guidance of an ex-NSA analyst. I recognize that I am extremely lucky to have had this chance, and that this kind of education is only available to a select set of people worldwide. I also don't have a solution to the problem of training the next generation of cryptographers. However, having yet another potentially compromised AES implementation written by a novice programmer is not something that I want to encourage. On Mon, May 11, 2015 at 6:12 AM, Sec_Aficionado secaficion...@gmail.com wrote: While implementing one's own security and/or cryptography is certainly not advisable for a novice (or even advanced programmers), creating cipher implementations from scratch is probably one of the best ways to learn and understand the intricacies of the problem at hand. Learning about the pitfalls and advantages of the algorithms is key for a future security expert. Moreover, denying someone access to help on an open source project is antithetical to the OSS philosophy. How can anyone hope to understand code that by its very nature is cryptic and complex if there's no one willing to help disentangle, at least at a high level, the routines and functions? InfoSec is a black art today, but it needs to get out of that mode. After the last few years it is clear that unless we open up the understanding of these disciplines, we will be at the mercy of experts with hidden agendas. Only educated users can hope to make correct use of cryptography, or be able to choose the best application for their needs. As we know, even a robust cipher is useless if utilized for the wrong purpose or poorly configured. We can't turn away those with a genuine interest in learning how to use cryptography without dooming ourselves to continue with the status quo. I appeal to those of you who routinely share your knowledge and try to make a difference here, that you provide some guidance and not turn away people with basic questions like this one. These are the users who may become one day contributors. They should be nurtured and not shunned. OK, I'll get off my soapbox now. Have a great week everyone. On May 10, 2015, at 5:58 PM, Mike Mohr akih...@gmail.com wrote: The task of implementing AES should not be undertaken by a novice programmer. Please save the world another heartbleed and pick something more in line with your skill level. On May 10, 2015 11:48 AM, konstantinos Alexiou konstantinako...@gmail.com wrote: Dear Sirs, I am new to C programming and i am trying to create an independent to libraries source code for demonstration purposes for AES-CTR mode.Could i have some help on doing that using the source code contained under crypto/aes. Thank you very much in advance. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Stand alone AES-CTR module
Hi, all... I think it wise to go back to the OP's stated objective, to create an independent to libraries source code for demonstration purposes for AES-CTR mode. The operative prepositional phrase here being for demonstration purposes. Thus, whether it is wise to implement one's own crypto library/engine/etc. in *production*, I see no particular reason why learning from creating one as a demonstration or proof of concept (and even providing such code here or elsewhere for critique) is such a bad thing. This list is replete with experienced practitioners. If this isn't a good place to critique such a demonstration or proof of concept, perhaps someone here knows of a better list (one perhaps not focused on using OpenSSL in particular, say crypto.stackexchange.com - adn that is not an endorsement, merely an example). On 05/11/2015 11:59 PM, Mike Mohr wrote: If you don't know about list comprehension in Python, you can simply construct a list in a loop to get the job done. The end result is the same no matter which approach you take. The same is not true for cryptography. While Sec_Aficionado is quite eloquent and makes several valid points, I think his overall argument does not hold water. I have audited the crypto implementations in a number of open-source projects over the years found wide variance in their quality. In one instance a popular piece of software included a feature which claimed to encrypt its data using AES-256. It turned out that the code copied the user's password directly into the key buffer, either padding with null bytes or truncating depending on the length. The data was then encrypted using AES-256 in ECB mode. The software's primary purpose was not cryptography, and it provided innovative and creative features otherwise. This type of bug is insidious, since it doesn't really protect the data in any meaningful way and lulls its users into a false sense of security. I am not advocating that the realm of information security be forever relegated to a select few. That is also dangerous, as Sec_Aficionado correctly pointed out. However, the study of cryptography should never be undertaken without the guidance of an experienced practitioner. I had the extraordinary opportunity to study information security at university under the guidance of an ex-NSA analyst. I recognize that I am extremely lucky to have had this chance, and that this kind of education is only available to a select set of people worldwide. I also don't have a solution to the problem of training the next generation of cryptographers. However, having yet another potentially compromised AES implementation written by a novice programmer is not something that I want to encourage. On Mon, May 11, 2015 at 6:12 AM, Sec_Aficionado secaficion...@gmail.com mailto:secaficion...@gmail.com wrote: While implementing one's own security and/or cryptography is certainly not advisable for a novice (or even advanced programmers), creating cipher implementations from scratch is probably one of the best ways to learn and understand the intricacies of the problem at hand. Learning about the pitfalls and advantages of the algorithms is key for a future security expert. Moreover, denying someone access to help on an open source project is antithetical to the OSS philosophy. How can anyone hope to understand code that by its very nature is cryptic and complex if there's no one willing to help disentangle, at least at a high level, the routines and functions? InfoSec is a black art today, but it needs to get out of that mode. After the last few years it is clear that unless we open up the understanding of these disciplines, we will be at the mercy of experts with hidden agendas. Only educated users can hope to make correct use of cryptography, or be able to choose the best application for their needs. As we know, even a robust cipher is useless if utilized for the wrong purpose or poorly configured. We can't turn away those with a genuine interest in learning how to use cryptography without dooming ourselves to continue with the status quo. I appeal to those of you who routinely share your knowledge and try to make a difference here, that you provide some guidance and not turn away people with basic questions like this one. These are the users who may become one day contributors. They should be nurtured and not shunned. OK, I'll get off my soapbox now. Have a great week everyone. On May 10, 2015, at 5:58 PM, Mike Mohr akih...@gmail.com mailto:akih...@gmail.com wrote: The task of implementing AES should not be undertaken by a novice programmer. Please save the world another heartbleed and pick something more in line with your skill level. On May 10, 2015 11:48 AM, konstantinos Alexiou konstantinako...@gmail.com
[openssl-users] Replacing RFC2712 (was Re: Kerberos)
On Fri, May 08, 2015 at 10:57:52PM -0500, Nico Williams wrote: I should have mentioned NPN and ALPN too. [...] A few more details: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. - The protocol MUST use GSS channel binding to TLS. - Use SASL/GS2 instead of plain GSS and you get to use an authzid (optional) and you get a builtin authorization status result message at no extra cost, and all while still using GSS. You get to optimize only the mechanism negotiation, and you get TLS w/ Kerberos (and others) and without PKIX (if you don't want it). See RFCs 7301, 5801, 5056, and 5929 (but note that the TLS session hash extension is required). Nico -- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Stand alone AES-CTR module
On Sun, May 10, 2015 at 5:58 PM, Mike Mohr akih...@gmail.com wrote: The task of implementing AES should not be undertaken by a novice programmer. Please save the world another heartbleed and pick something more in line with your skill level. Maybe I am not parsing it correctly It sounds like he wants to use something like AES/CTR from an existing library like OpenSSL; and not implement AES from the ground up. Also, OpenSSL is susceptible to side channel attacks due to its table driven implementation. So its not clear to me how he could do much worse since a break is a break. You are either pregnant or you are not. There's no degree's of pregnancy, like being half pregnant. (There's some hand waiving above since it depends on the threat model. But you usually don't exclude threats because they are inconvenient or don't meet your efficiency goals. That's similar to what Browsers do in their threat models - they exclude inconvenient stuff or stuff that conflicts with their usability goals. That's one of the reasons browser security is such a joke). Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Stand alone AES-CTR module
On Sun, May 10, 2015 at 2:47 PM, konstantinos Alexiou konstantinako...@gmail.com wrote: Dear Sirs, I am new to C programming and i am trying to create an independent to libraries source code for demonstration purposes for AES-CTR mode.Could i have some help on doing that using the source code contained under crypto/aes. You should use the EVP interfaces; see EVP Symmetric Encryption and Decryption on the OpenSSL wiki (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption). For counter mode, never reuse a counter or nonce within a security context. CTR mode provides confidentiality only, and its usually not enough to meet expectations of security. You usually want both confidentiality and authenticity assurances. The authenticity assurances provide both entity authentication and data integrity. Its usually a better notion of security and its called Authenticated Encryption. For Authenticated Encryption, you should also use the EVP interfaces; see EVP Authenticated Encryption and Decryption on the OpenSSL wiki (https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption). GCM mode is usually the mode you use when CWC mode (single pass) or EAX mode (double pass; slightly better than GCM) is not available. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject[*] TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. [*] Except when employing unauthenticated encrypted communication to mitigate passive monitoring (oportunistic security). -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
