Re: [openssl-users] The evolution of the 'master' branch
I think Jakob’s real concern (as expressed to me off-list a month or so ago) is that OpenSSL’s libcrypto will become entirely hidden. I found several of his comments confusing until he mentioned that. So, I think the fair question to be asking is: Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available? Thanks! TOM On Feb 6, 2015, at 11:03 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 05/02/2015 00:42, Salz, Rich wrote: Not much on that page so far, not even a kill list of intended victims except an admission that EAY's popular DES library can no longer be accessed via the copy in OpenSSL. Yup. Pretty empty. Over the coming year there will be more. I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. , making it much harder to use the library with experimental or non-standard algorithms and methods. Well, not really much harder. I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features. Don't forget, *you have the source* Hack away. Do what you want. And having a standard API that any of your consumers use will benefit your consumers greatly. And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit: THEIR CODE DOES NOT HAVE TO RECOMPILE. As an implementor, your work is a bit harder. For your users, it is much easier. Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change. (Emphasis on ALMOST :) To us, this is clearly the right trade-off to make. You seem to misunderstand the scenario: My scenario is: 1. Load an unchanged shared libcrypto.so.1.1 provided by an OS distribution. 2. Implement / use / experiment with non-standard methods (such as new modes of operation or new zero-knowledge proofs) by calling the functions that are exported by libcrypto out of the box. The higher level libssl is not used for anything. Your scenario is: 1. Extend the higher level stuff (TLS1.2, CMS etc.) with non- standard methods (such as new modes of operation or new signature forms). 2. Inject this new functionality into existing applications that use OpenSSL in generic ways, such as wget and WebKit browsers. My scenario got great advantages from the large number of fundamental interfaces exported from libcrypto.so.1.0 and will automatically benefit when a new patch release of OpenSSL is installed on the system (e.g. to fix a timing attack on one of the algorithm implementations). Having to create a custom libnotquitecrypto.so.1.1 would not do this, and distributing such a library as source patches became much harder when you reformatted the source. Looking at the reverse dependencies in Debian, the following projects probably use low level libcrypto interfaces to do interesting things: afflib, asterisk, bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools, faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd, hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC, ldnsutils, apache mod-auth-cas, apache mod-auth-openid, perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada, StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc, openssh, rdd, rdesktop, rsyncrypto, samdump, tor, tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse. *This is only a rough list based on features claimed by OpenSSL-depending packages* Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ? Use whatever works best for you, and your consumers/customers. Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim. I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ 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] The evolution of the 'master' branch
Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available? Absolutely not. Thanks for asking! ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
On 10/02/15 21:16, Tom Francis wrote: I think Jakob’s real concern (as expressed to me off-list a month or so ago) is that OpenSSL’s libcrypto will become entirely hidden. I found several of his comments confusing until he mentioned that. So, I think the fair question to be asking is: Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available? No. There is a plan to make most structures opaque, with accessor functions provided instead if required (in much the same way as we are doing with libssl). The bn stuff has already had that treatment applied. There is also a discussion about whether low-level cipher APIs should be removed in favour of EVP or not. It's a discussion. No decisions or consensus either way at the moment. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
On 07/02/2015 12:12, Michael Felt wrote: From someone who does NOT understand the in's and out's of what people (developers and users) have been using openSSL for. My first reaction is: have developers been using openSSL, or has it gone to abusing it? For the sake of argument - let's say just use as it has always been intended. Fundamentally, since its inception by EAY years ago, OpenSSL has provided two things to other software developers: A very popular implementation of the SSL protocols defined by Netscape/Mozilla/IETF, and an equally popular library of fundamental cryptographic building blocks such as large numbers and various types of encryption and decryption. My criticism of the OpenSSL changes in the future version 1.1.0 is that they are removing the most flexible building blocks from the part that is intended to be used. Many technologies - especially related to security - whether it be a big log through 'something', to skeleton keys', to digital keys, etc - we want to be able to trust our locks. When the lock technology is no longer trustworthy - whether it be packaging (which is what the discussion sounds like atm) or unrepairable concerns with the technology asis - we change our locks. 2014 saw some widely published problems with various SSL variants. Heartbleed was a programming error found *only* in the OpenSSL SSL code and did not affect the handful of competing SSL implementations (such as the NSS one by Mozilla and the STUNNEL one by Microsoft). Essentially, heartbleed allowed people to put a hook through the keyhole and steal the key from behind the locked door. Poodle was a new way to attack a known weakness in the old version 3.0 of the SSL protocol, affecting all implementations, combined with a weakness in how Web Browsers work around bad SSL libraries that refuse to even reply to requests for protocol version 3.1 (TLS 1.0). On top of that, it turned out that a few minor competing SSL implementations (not OpenSSL, NSS and STUNNEL) never implemented the TLS 1.0 protection against the known weakness, leading to a rumor that poodle affected all TLS 1.0 implementations, and not just the few broken ones. Not everyone changes locks at the same moment in time. urgency depends on need, i.e., what is at risk. I started following these discussions because I am concerned (remember I am not really interested in the inner workings. I just think my locks are broken and wondering if it is time to change to something that maybe can do less - but what it does, does it better than what I have now. Regardless of the choices made by openssl - people outside openssl have needs and are looking at alternatives. To someone like me it is obvious something must change - even if technically it is cosmetic - because (open)SSL is losing the trust of it's users. As a user - I need a alternative. And just as I stopped using telnet/ftp/rsh/etc- because I could not entrust the integrity of my systems when those doors were open - so are my concerns re: (open)SSL. In short, is SSL still secure? And, very simply, as an un-knowledgeable user - given the choice of a library that does something well - and that's it, versus something else that does that - but leaves room for 'experiments' - Not on my systems. Experiment in experiment-land. My two bits. On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell m...@openssl.org mailto:m...@openssl.org wrote: On 06/02/15 16:03, Jakob Bohm wrote: I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. ...and, Rich said in a previous email (in response to your comment): I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. I'd like to stress that there has been no decision. In fact we're not even close to a decision on that at the moment. Whilst this has certainly been discussed I don't believe we are near to a consensus view at the moment. So whilst there is a good chance of that happeningthere's also a very good chance of it not. It is still under discussion. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
From someone who does NOT understand the in's and out's of what people (developers and users) have been using openSSL for. My first reaction is: have developers been using openSSL, or has it gone to abusing it? For the sake of argument - let's say just use as it has always been intended. Many technologies - especially related to security - whether it be a big log through 'something', to skeleton keys', to digital keys, etc - we want to be able to trust our locks. When the lock technology is no longer trustworthy - whether it be packaging (which is what the discussion sounds like atm) or unrepairable concerns with the technology asis - we change our locks. Not everyone changes locks at the same moment in time. urgency depends on need, i.e., what is at risk. I started following these discussions because I am concerned (remember I am not really interested in the inner workings. I just think my locks are broken and wondering if it is time to change to something that maybe can do less - but what it does, does it better than what I have now. Regardless of the choices made by openssl - people outside openssl have needs and are looking at alternatives. To someone like me it is obvious something must change - even if technically it is cosmetic - because (open)SSL is losing the trust of it's users. As a user - I need a alternative. And just as I stopped using telnet/ftp/rsh/etc- because I could not entrust the integrity of my systems when those doors were open - so are my concerns re: (open)SSL. In short, is SSL still secure? And, very simply, as an un-knowledgeable user - given the choice of a library that does something well - and that's it, versus something else that does that - but leaves room for 'experiments' - Not on my systems. Experiment in experiment-land. My two bits. On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell m...@openssl.org wrote: On 06/02/15 16:03, Jakob Bohm wrote: I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. ...and, Rich said in a previous email (in response to your comment): I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. I'd like to stress that there has been no decision. In fact we're not even close to a decision on that at the moment. Whilst this has certainly been discussed I don't believe we are near to a consensus view at the moment. So whilst there is a good chance of that happeningthere's also a very good chance of it not. It is still under discussion. Matt ___ 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] The evolution of the 'master' branch
On 05/02/2015 00:42, Salz, Rich wrote: Not much on that page so far, not even a kill list of intended victims except an admission that EAY's popular DES library can no longer be accessed via the copy in OpenSSL. Yup. Pretty empty. Over the coming year there will be more. I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. , making it much harder to use the library with experimental or non-standard algorithms and methods. Well, not really much harder. I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features. Don't forget, *you have the source* Hack away. Do what you want. And having a standard API that any of your consumers use will benefit your consumers greatly. And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit: THEIR CODE DOES NOT HAVE TO RECOMPILE. As an implementor, your work is a bit harder. For your users, it is much easier. Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change. (Emphasis on ALMOST :) To us, this is clearly the right trade-off to make. You seem to misunderstand the scenario: My scenario is: 1. Load an unchanged shared libcrypto.so.1.1 provided by an OS distribution. 2. Implement / use / experiment with non-standard methods (such as new modes of operation or new zero-knowledge proofs) by calling the functions that are exported by libcrypto out of the box. The higher level libssl is not used for anything. Your scenario is: 1. Extend the higher level stuff (TLS1.2, CMS etc.) with non- standard methods (such as new modes of operation or new signature forms). 2. Inject this new functionality into existing applications that use OpenSSL in generic ways, such as wget and WebKit browsers. My scenario got great advantages from the large number of fundamental interfaces exported from libcrypto.so.1.0 and will automatically benefit when a new patch release of OpenSSL is installed on the system (e.g. to fix a timing attack on one of the algorithm implementations). Having to create a custom libnotquitecrypto.so.1.1 would not do this, and distributing such a library as source patches became much harder when you reformatted the source. Looking at the reverse dependencies in Debian, the followingprojects probably use low level libcrypto interfaces to do interesting things: afflib, asterisk, bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools, faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd, hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC, ldnsutils, apache mod-auth-cas, apache mod-auth-openid, perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada, StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc, openssh, rdd, rdesktop, rsyncrypto, samdump, tor, tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse. *This is only a rough list based on features claimed by OpenSSL-depending packages* Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ? Use whatever works best for you, and your consumers/customers. Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim. I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
Thanks for your detailed reply. Not sure what else I can say except that we disagree. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
On 06/02/15 16:03, Jakob Bohm wrote: I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. ...and, Rich said in a previous email (in response to your comment): I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. I'd like to stress that there has been no decision. In fact we're not even close to a decision on that at the moment. Whilst this has certainly been discussed I don't believe we are near to a consensus view at the moment. So whilst there is a good chance of that happeningthere's also a very good chance of it not. It is still under discussion. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
On 03/02/2015 23:02, Rich Salz wrote: As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's commit of the other day, this is starting to happen now. We know this will inconvenience people as some applications no longer build. We want to work with maintainers to help them migrate, as we head down this path. We have a wiki page to discuss this effort. It will eventually include tips on migration, application and code updates, and anything else the community finds useful. Please visit: http://wiki.openssl.org/index.php/1.1_API_Changes Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Not much on that page so far, not even a kill list of intended victims except anadmission that EAY's popular DES library can no longer be accessed via the copyin OpenSSL. I fear that this is an indication that you will be killing off all the othernon-EVP entrypoints in libcrypto, making it much harder to use thelibrary with experimental or non-standard algorithms and methods. Just consider how hard it would now be to use libcrypto to implement stuff like AES-GCM (if it was not already in the library) or any of the block modes that were proposed in the FIPS process, but not standardised by NIST (and thus not included in EVP). With the classic non-EVP API, it is trivial to wrap a custom mode around the basic DES/AES/IDEA/... block functions. And this is just one example of the flexibility provided by not going through the more rigid EVP API. Should everyone not doing just TLS1.2 move to a different librarynow, such as crypto++ ? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
Not much on that page so far, not even a kill list of intended victims except an admission that EAY's popular DES library can no longer be accessed via the copy in OpenSSL. Yup. Pretty empty. Over the coming year there will be more. I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. , making it much harder to use the library with experimental or non-standard algorithms and methods. Well, not really much harder. I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features. Don't forget, *you have the source* Hack away. Do what you want. And having a standard API that any of your consumers use will benefit your consumers greatly. And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit: THEIR CODE DOES NOT HAVE TO RECOMPILE. As an implementor, your work is a bit harder. For your users, it is much easier. Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change. (Emphasis on ALMOST :) To us, this is clearly the right trade-off to make. Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ? Use whatever works best for you, and your consumers/customers. Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim. /r$ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] The evolution of the 'master' branch
As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's commit of the other day, this is starting to happen now. We know this will inconvenience people as some applications no longer build. We want to work with maintainers to help them migrate, as we head down this path. We have a wiki page to discuss this effort. It will eventually include tips on migration, application and code updates, and anything else the community finds useful. Please visit: http://wiki.openssl.org/index.php/1.1_API_Changes Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
