Re: [CentOS] Can we trust RedHAt encryption tools?
From: Liam O'Toole liam.p.oto...@gmail.com That sounds worrying. Could you elaborate, or provide a citation? Remember this? http://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/ The whole SSL certificates system is not to be trusted if (some of) the guys who manage it are corrupt. JD ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 2014-01-09, Robert Moskowitz r...@htt-consult.com wrote: (...) You want to talk about leaky code? Look how corporate mail proxies work to enable them to read encrypted emails. Simple lying about certs. That sounds worrying. Could you elaborate, or provide a citation? -- Liam ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/10/2014 09:22 AM, Liam O'Toole wrote: On 2014-01-09, Robert Moskowitz r...@htt-consult.com wrote: (...) You want to talk about leaky code? Look how corporate mail proxies work to enable them to read encrypted emails. Simple lying about certs. That sounds worrying. Could you elaborate, or provide a citation? This is quite common. We were discussing this at IETF in Nov. Right now I forget the law which allows employers complete access to employee emails, but as such when the client asks for the recipients cert, the server retrieves it, creates a fake one that is presented to the client. The client encrypts the email, and sends it to the server. The server decrypts, stores the content per corporate policy, then encrypts with the appropriate cert. Well actually it is a bit more than that, as only the symmetric key is encrypted with the cert's key. This is old stuff for me; I did secure mail a decade ago, and this work around was well known then. Also works well for web clients through the corporate http proxy. Actually it is easier for web transactions than email. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On Thu, January 9, 2014 17:52, m.r...@5-cent.us wrote: Robert Moskowitz wrote: On 01/09/2014 05:28 PM, John R Pierce wrote: On 1/9/2014 2:20 PM, Eero Volotinen wrote: It might be easier to compromise security of commercial products as source code is not available. they seem to have succeeded in compromising STANDARDS and ALGORITHMS, to heck with implementations. Only algorithm they compromised was an RNG that got pretty strong thumbs down from the real cryptographers. They have not compromised any IETF standard; maybe kept quite about a problem, but have not put holes in any. Most of our problems with TLS is implementations and backwards compatiblity options. Not quite - anyone mandated to POSIX standards are effectively mandated to use the compromised algorithms, as I understand it. mark Well, regardless of my thoughts on the ethics of this situation and my opinion about those who do these sorts of things, I have continued to research this issue. I have discovered that there is a great deal of literature respecting the weakness of the RNG and PRNG processes implemented on headless hosts, in particular headless hosts that are virtualised. Given the essential nature of true random number generation to cryptographically secure key creation this represents a significant weak point on such hosts. I am not going to reiterate or summarize any of this here because you can find these discussions easily enough via Google. However, I have developed a small script to alleviate the problem to some degree based on the writings and works of others. This requires the epel repository be enabled: #!/bin/bash cat /proc/sys/kernel/random/entropy_avail yum install dieharder haveged rng-tools -q -y cat /etc/sysconfig/rngd sed -i 's:EXTRAOPTIONS=:EXTRAOPTIONS=-r /dev/urandom:' /etc/sysconfig/rngd cat /etc/sysconfig/rngd chkconfig --level 2345 haveged on ; chkconfig --level 2345 rngd on service haveged start ; service rngd start cat /proc/sys/kernel/random/entropy_avail This increased the mean amount of entropy present in /dev/random on the systems I installed these packages on from ~176 bits to ~2048 bits. I continue to look into other related matters. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 02:52 PM, m.r...@5-cent.us wrote: Not quite - anyone mandated to POSIX standards are effectively mandated to use the compromised algorithms, as I understand it. That's news to me. Citation? Recently, there was a discussion amongst BSD devs and they concluded that they don't trust hardware RNG either, deciding instead to add their randomness to other sources before going to /dev/random. http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ Lastly, we should all thank this neckbeard who's been banging the gong all along, and was right: http://schestowitz.com/Weblog/archives/2013/07/15/ -Ben ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 1/9/2014 15:52, m.r...@5-cent.us wrote: Robert Moskowitz wrote: Only algorithm they compromised was an RNG that got pretty strong thumbs down from the real cryptographers. They have not compromised any IETF standard; Not quite - anyone mandated to POSIX standards are effectively mandated to use the compromised algorithms, as I understand it. I think you mean FIPS 140-2, not POSIX: http://goo.gl/nLTCF8 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 2014-01-06 11:28, James B. Byrne wrote: I believe that the issue is of pressing interest to the entire community and I would like to read what others have to say on the matter. I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! We can't trust the software or the hardware any longer. When the problem runs this deep, what can anyone do? The NSA program has effectively removed my trust with every single U.S. (actually, 5 eyes) based tech company. I can only imagine what RMS thinks about all of this. If he hadn't fought for so long for free software, we would all truly be up shits creek. Don't trust proprietary anything. Use free software - it'll be fixed sooner and properly before anything else. -- Kanwar Ranbir Sandhu ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On Thu, Jan 9, 2014 at 3:27 PM, Kanwar Ranbir Sandhu m3fr...@thesandhufamily.ca wrote: We can't trust the software or the hardware any longer. When the problem runs this deep, what can anyone do? The NSA program has effectively removed my trust with every single U.S. (actually, 5 eyes) based tech company. I can only imagine what RMS thinks about all of this. If he hadn't fought for so long for free software, we would all truly be up shits creek. If you start with the assumption that Intel/AMD processors and the gcc compiler are backdoored, what's left, US or not? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce pie...@hogranch.com wrote: On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. It might be easier to compromise security of commercial products as source code is not available. -- Eero ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 1/9/2014 2:20 PM, Eero Volotinen wrote: It might be easier to compromise security of commercial products as source code is not available. they seem to have succeeded in compromising STANDARDS and ALGORITHMS, to heck with implementations. -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 04:55 PM, John R Pierce wrote: On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. I work with real cryptographers. I do not consider myself one. I am a crypto protocol designer; a different breed. You basically trust the math and the arguments put forward by the real cryptographers. There is LOTS of public review and comment. But we recognize that the largest employer of mathmeticians is the NSA. If there is an exploitable lever, they will know about it before we will; I have a real experience with this back with IPsec and the implicit IV ESP proposal. So some programmer has to take the math for the crypto algorithms and implement it correctly. In many cases, this ends up being done at least in firmware, and in some cases actual chips (I work mostly, these days, with sensors). Then you have to trust the likes of me to design the crypto protocol right. There are lots of subtle traps here; I have the scars to show it. Then programmers again have to take our crypto protocols and do them right You get the picture. If you do not trust the NIST (read NSA) EC curves, you have two choices. Dan Berstein's curves (Dan is a long time anti guy, and Bruce Schneier is a long time friend of Dan, and me). Or the Braintrust curves; they are published in an RFC (seems good to me, and I have heard some good references on their work). But really, the NIST curves have been under extensive review. They are used both by the govs and banking; NSA knows if they can figure out weaknesses, so can other large gov funded math teams. The big event was the RNG that NSA had added, and the public community came down on it almost from the get-go. You want to talk about leaky code? Look how corporate mail proxies work to enable them to read encrypted emails. Simple lying about certs. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 05:15 PM, Les Mikesell wrote: On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce pie...@hogranch.com wrote: On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. Bruce's twofish was better; it was his AES submission. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 05:20 PM, Eero Volotinen wrote: I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. It might be easier to compromise security of commercial products as source code is not available. Yes and no. Like with anything. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Robert Moskowitz wrote: On 01/09/2014 05:15 PM, Les Mikesell wrote: On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce pie...@hogranch.com wrote: On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. Bruce's twofish was better; it was his AES submission. Ah, thanks, Rob, I was about to post that Bruce had recommended something better than his old Blowfish (and yes, I've some small acquaintance with Bruce - via GT). mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 05:28 PM, John R Pierce wrote: On 1/9/2014 2:20 PM, Eero Volotinen wrote: It might be easier to compromise security of commercial products as source code is not available. they seem to have succeeded in compromising STANDARDS and ALGORITHMS, to heck with implementations. Only algorithm they compromised was an RNG that got pretty strong thumbs down from the real cryptographers. They have not compromised any IETF standard; maybe kept quite about a problem, but have not put holes in any. Most of our problems with TLS is implementations and backwards compatiblity options. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On Thu, Jan 9, 2014 at 4:32 PM, Robert Moskowitz r...@htt-consult.com wrote: I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. Bruce's twofish was better; it was his AES submission. But didn't that come later? With nothing else to go on, that would make me think that it is more likely to have been influenced by whatever means corrupted the others. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Robert Moskowitz wrote: On 01/09/2014 05:28 PM, John R Pierce wrote: On 1/9/2014 2:20 PM, Eero Volotinen wrote: It might be easier to compromise security of commercial products as source code is not available. they seem to have succeeded in compromising STANDARDS and ALGORITHMS, to heck with implementations. Only algorithm they compromised was an RNG that got pretty strong thumbs down from the real cryptographers. They have not compromised any IETF standard; maybe kept quite about a problem, but have not put holes in any. Most of our problems with TLS is implementations and backwards compatiblity options. Not quite - anyone mandated to POSIX standards are effectively mandated to use the compromised algorithms, as I understand it. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 05:37 PM, Les Mikesell wrote: On Thu, Jan 9, 2014 at 4:32 PM, Robert Moskowitz r...@htt-consult.com wrote: I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. Bruce's twofish was better; it was his AES submission. But didn't that come later? With nothing else to go on, that would make me think that it is more likely to have been influenced by whatever means corrupted the others. It was back in the heady days of finding a replacement for DES and 3DES. Rivest had his RC5 (there are calls again for a streaming cipher, and NIST may well 'pick' one this year). Kennedy had SAFER+ (used in Bluetooth, but SAFER+ was eliminated for AES because it was highly dependent on your RNG. Ask bluetooth vendors about their RNG). The peer review was brutal. Bruce himself will admit to issues found surrounding twofish. Some question the changes NSA had made with RInjdal, but again, massive peer review. And you see that review regularly. We wanted the GCM mode of operation for IEEE 802.1AE, and NSA offered some tweaks to tighten it up. Just a bit before (grumble, what was the profs name) made the same recommendation. The big things they help with. Too much public review and too many profs looking for research for their students (why we are moving away from SHA1, eventhough further work is showing it to be stronger that we thought). It is the subtle things around the use of the algorithms and protocols they go after. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
I was shocked and horrified to find out that RHEL (and presumably CentOS) and Ubuntu no longer implement the 'rot13' program. Cheers, Cliff On Fri, Jan 10, 2014 at 11:32 AM, Robert Moskowitz r...@htt-consult.comwrote: On 01/09/2014 05:15 PM, Les Mikesell wrote: On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce pie...@hogranch.com wrote: On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. Bruce's twofish was better; it was his AES submission. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 1/9/2014 3:33 PM, Cliff Pratt wrote: I was shocked and horrified to find out that RHEL (and presumably CentOS) and Ubuntu no longer implement the 'rot13' program. tr A-Za-z N-ZA-Mn-za-m infile outfile example... $ echo this is a message | tr A-Za-z N-ZA-Mn-za-m guvf vf n zrffntr $ echo guvf vf n zrffntr | tr A-Za-z N-ZA-Mn-za-m this is a message -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Thanks! I got similar suggestions when I mentioned this at work. I was of course joking about rot13. Cheers, Cliff On Fri, Jan 10, 2014 at 12:41 PM, John R Pierce pie...@hogranch.com wrote: On 1/9/2014 3:33 PM, Cliff Pratt wrote: I was shocked and horrified to find out that RHEL (and presumably CentOS) and Ubuntu no longer implement the 'rot13' program. tr A-Za-z N-ZA-Mn-za-m infile outfile example... $ echo this is a message | tr A-Za-z N-ZA-Mn-za-m guvf vf n zrffntr $ echo guvf vf n zrffntr | tr A-Za-z N-ZA-Mn-za-m this is a message -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/09/2014 06:33 PM, Cliff Pratt wrote: I was shocked and horrified to find out that RHEL (and presumably CentOS) and Ubuntu no longer implement the 'rot13' program. But they implement the NULL cipher as part of IPsec. Cheers, Cliff On Fri, Jan 10, 2014 at 11:32 AM, Robert Moskowitz r...@htt-consult.comwrote: On 01/09/2014 05:15 PM, Les Mikesell wrote: On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce pie...@hogranch.com wrote: On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote: I think everyone should assume the entire ecosystem is compromised and shouldn't trust anything. Code should be reviewed and bugs/weaknesses removed IMMEDIATELY. The problem is obviously not everyone is a programmer and not everyone will have the knowledge to understand how to fix/improve the security issues. Of course, some software is still good, but who's going to verify that and when? If you don't use free software, you're a goner because now you have no ability whatsoever to audit the code! I've programmed for 40 years, and I don't understand encryption algorithms nor can I evaluate their strengths and weaknesses. I know very few programmers who can. None personally, in fact. I always just assumed that blowfish was good precisely because it wasn't the one that was recommended/promoted by the groups likely to be compromised. But, I try to stay out of politics so I don't worry much about keeping secrets anyway. Bruce's twofish was better; it was his AES submission. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) looks (at least to me) like magic and any average dev would not (be able to) see evil code in the middle of it...And it is not only an NSA/USA thing, since it seems many countries are cooperating or doing the same... By example, in the middle of the Snowden revelations, France just passed a blanket spying law (without judicial supervision)! Anyway, I think that having a 100% trustable environment is more and more an utopia. What? Pessimistic? Me? Yep! JD ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
John Doe wrote: After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) One thing on the positive side: the last few months, I think a *lot* of folks are eyeballing this stuff, specifically looking for issues, and probably some are going back to things that they said I dunno... but I'll come back to look at this someday. I *suspect* that within about six months, it'll be as relatively safe as it was maybe 10 years ago. Of course, we'll need some wakeup call to look at it all again in 10 years. In the meantime, I think things are getting safer, relatively. H, speaking of BIOS, wonder if this will impact the push for UEFI mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHat encryption tools?
On Mon, January 6, 2014 16:51, m.r...@5-cent.us wrote: Looks like it's rtrying to install it, not just build it. In the first example, you're trying to replace the existing /usr/bin/strip, which only root can do. Are you doing make, or make install? I started out by using the openssl.spec file for openssl-1.0.1f directly from openssl.org. The contents of that file are provided at http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=openssl.spec;hb=HEAD. What I then do download the source from openssl.org and put that into ~/rpmbuild/SOURCES and extract it. I then copy ~/rpmbuild/SOURCES/openssl-1.0.1f/openssl.spec into ~/rpmbuild/SPECS and run the following commands: mock --buildsrpm --sources=./rpmbuild/SOURCES --spec=./rpmbuild/SPECS/openssl.spec mock --no-clean --rebuild --root=default /var/lib/mock/epel-6-x86_64/result/openssl-1.0.1f-1.src.rpm This gives the error reported above. I realize that this is a naive approach but I after looking at the Redhat openssl.spec file I thought it best to start with the base files provided by the origin and work out any build problems one by one making the absolute minimum number of changes possible. The nearest equivalent Redhat openssl.spec file that I found is that used by Fedora 20 for openssl-1.0.1e and its contents are displayed here: http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl.spec?h=f20 From what I have read elsewhere, Fedora/Redhat openssl begins with a set of modified source files. The spec file additionally applies about 43 patch files of which 27 alter the functionality of the package. It is not within my ability to determine what effect of the modifications to the source and these additional patches have on the integrity of the openssl provided with RHEL. Is there any third party in our community which does? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
What about selinux - wasn't that originally done by the NSA? On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote: John Doe wrote: After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) One thing on the positive side: the last few months, I think a *lot* of folks are eyeballing this stuff, specifically looking for issues, and probably some are going back to things that they said I dunno... but I'll come back to look at this someday. I *suspect* that within about six months, it'll be as relatively safe as it was maybe 10 years ago. Of course, we'll need some wakeup call to look at it all again in 10 years. In the meantime, I think things are getting safer, relatively. H, speaking of BIOS, wonder if this will impact the push for UEFI mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Just audit the source code... 7.1.2014 16.42 kirjoitti Steve Clark scl...@netwolves.com: What about selinux - wasn't that originally done by the NSA? On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote: John Doe wrote: After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) One thing on the positive side: the last few months, I think a *lot* of folks are eyeballing this stuff, specifically looking for issues, and probably some are going back to things that they said I dunno... but I'll come back to look at this someday. I *suspect* that within about six months, it'll be as relatively safe as it was maybe 10 years ago. Of course, we'll need some wakeup call to look at it all again in 10 years. In the meantime, I think things are getting safer, relatively. H, speaking of BIOS, wonder if this will impact the push for UEFI mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote: John Doe wrote: After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) Yeah didn't Dennis Richie modify the C compiler to insert a backdoor for him when ever the compiler saw login.c was being programmed? One thing on the positive side: the last few months, I think a *lot* of folks are eyeballing this stuff, specifically looking for issues, and probably some are going back to things that they said I dunno... but I'll come back to look at this someday. I *suspect* that within about six months, it'll be as relatively safe as it was maybe 10 years ago. Of course, we'll need some wakeup call to look at it all again in 10 years. In the meantime, I think things are getting safer, relatively. H, speaking of BIOS, wonder if this will impact the push for UEFI mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 07/01/2014 15:52, Steve Clark wrote: On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote: John Doe wrote: After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) Yeah didn't Dennis Richie modify the C compiler to insert a backdoor for him when ever the compiler saw login.c was being programmed? I think that was ken... -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 07/01/2014 15:55, Giles Coochey wrote: On 07/01/2014 15:52, Steve Clark wrote: On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote: John Doe wrote: After all the news about backdoors, planted bugs or weakened standards in apps, in routers, hardware firmwares, etc... these days, can we trust anything? Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) Yeah didn't Dennis Richie modify the C compiler to insert a backdoor for him when ever the compiler saw login.c was being programmed? I think that was ken... http://cm.bell-labs.com/who/ken/trust.html -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On Tue, Jan 7, 2014 at 9:55 AM, Giles Coochey gi...@coochey.net wrote: Can we trust the bios? Can we trust the compiler not to stealthily inject a backdoor in the compiled version of a clean code?Given that most entries from the The International Obfuscated C Code Contest (http://www.ioccc.org/) Yeah didn't Dennis Richie modify the C compiler to insert a backdoor for him when ever the compiler saw login.c was being programmed? I think that was ken... You are underestimating government agencies. I think they'd go for a backdoor in the CPU itself - harder to find and only a few companies to corrupt to mange it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
James B. Byrne wrote: Recently I have been deeply troubled by evidence revealing the degree to which U.S. based corporations (well actually all resident in any of the so-called 5-eyes countries) appear to have rolled over and assumed the position with respect to NSA inspired pressure to cripple public key encryption and facilitate intrusions into their software products. This has engendered in me a significant degree of doubt surrounding the integrity of RHEL; and therefore of CentOS since it claims to be a bug for bug, and therefore an exploit for exploit, copy of RHEL. snip Where this discourse is leading is to is the question of whether or not CentOS should provide OpenSSL built from clean sources as an extra or plus package and perhaps httpd, sshd and ssh-client and related pki based/reliant packages as well. Similarly, should CentOS.org provide tested spec files that will provide individual system admins a simple method of building these packages from source? I think that CentOS.org probably should provide this but I am afraid that I cannot make a strong public case. Suffice that my belief is informed from snip I agree, but I just don't know how much in the way of manhours that would involved. However, if you do get it all built, and build packages out of them, there is an extras? contribs? repo, and I'd encourage you to submit it for that. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
I agree, but I just don't know how much in the way of manhours that would involved. However, if you do get it all built, and build packages out of them, there is an extras? contribs? repo, and I'd encourage you to submit it for that. RHEL nowdays supports already Elliptic Curve on openssl. -- Eero ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
RHEL nowdays supports already Elliptic Curve on openssl. Which complete misses the point. First, the initial settings of the EC are significant in determining the strength of the resulting cipher. There is considerable evidence that suggests that some of these default settings have been proposed by or adopted on behalf of interests that would benefit from having an easily compromised encryption technique. While the algorithm may be strong a carefully crafted initial setting might be all it takes to render it vulnerable. Second, the delay in providing ECC in itself taken together with the abrupt and unexplained resolution to this matter subsequent to Snowden's revelations respecting the complicity of commercial entities in furthering illicit surveillance raises my suspicion that there is more to this than meets the eye. We are talking about a matter of trust and I am afraid to say that my suspicions of the motives of large commercial enterprises in matters of trust looms large in my thinking. If it turns out to be the case that RH withheld ECC from its users because of the pressure of some external interest we cannot be certain that this was the only item that was affected. I am really at a loss as to how to proceed. Do I move off CentOS entirely? Where to? What other distribution of similar stature exists that is itself not subject to exactly the same forces that may have been brought to bear on RedHat. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Eero Volotinen wrote: mark wrote: I agree, but I just don't know how much in the way of manhours that would involved. However, if you do get it all built, and build packages out of them, there is an extras? contribs? repo, and I'd encourage you to submit it for that. RHEL nowdays supports already Elliptic Curve on openssl. Um, I guess you haven't read the news lately - the most used, POSIX-mandated elliptic curve is backdoored by the US NSA - when the standards committee was writing the standard, they pushed the backdoored version. https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html From one of the linked-two essays: As was revealed today, the NSA also works with security product vendors to ensure that commercial encryption products are broken in secret ways that only it knows about. We know this has happened historically: CryptoAG and Lotus Notes are the most public examples, and there is evidence of a back door in Windows. A few people have told me some recent stories about their experiences, and I plan to write about them soon. Basically, the NSA asks companies to subtly change their products in undetectable ways: making the random number generator less random, leaking the key somehow, adding a common exponent to a public-key exchange protocol, and so on. If the back door is discovered, it's explained away as a mistake. And as we now know, the NSA has enjoyed enormous success from this program --- end excerpt --- http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Um, I guess you haven't read the news lately - the most used, POSIX-mandated elliptic curve is backdoored by the US NSA - when the Well, as you know backdoored EC Dual DBRG is not working at all on openssl: http://marc.info/?l=openssl-announcem=138747119822324 -- Eero ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
Eero Volotinen wrote: Um, I guess you haven't read the news lately - the most used, POSIX-mandated elliptic curve is backdoored by the US NSA - when the Well, as you know backdoored EC Dual DBRG is not working at all on openssl: http://marc.info/?l=openssl-announcem=138747119822324 That I had not seen. I really like the we will not fix this bug. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
I am doing a bit of investigative work to see just how hard it is to build openssl for myself. The source from openssl.org is readily available and the spec file provided seems fairly usable. However, I am seeing lots of errors similar to this when I try to build it using mock: + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/openssl-1.0.1f-1.x86_64/usr/lib64/libcrypto.so.1.0.0'; reason: Permission denied What am I tripping over? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
James B. Byrne wrote: I am doing a bit of investigative work to see just how hard it is to build openssl for myself. The source from openssl.org is readily available and the spec file provided seems fairly usable. However, I am seeing lots of errors similar to this when I try to build it using mock: + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/openssl-1.0.1f-1.x86_64/usr/lib64/libcrypto.so.1.0.0'; reason: Permission denied What am I tripping over? Looks like it's rtrying to install it, not just build it. In the first example, you're trying to replace the existing /usr/bin/strip, which only root can do. Are you doing make, or make install? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
