<div dir="ltr">Don't get me wrong; I trust the open source community far more than I would trust a proprietary source. But even Eric S. Raymond admits that in the case of Heartbleed, the system didn't act as it should (<a href="http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html">http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html</a>). Two years is a long time to find a bug. But yes, it did get fixed quickly after that, whereas we've seen cases where Microsoft has dragged their feet on several bugs over several years after their discovery.<div>
<br></div><div>But this is getting away from my original comment. What I said was that _if_ the NSA had a backdoor or trick, then it really doesn't matter if you're using 1024 or 4096 bit encryption. They'll read your mail regardless. Whether or not they actually do have a hack is anybody's guess. The fact that they knew about Heartbleed two years ago and never told anyone just goes to prove you can't trust them. Open Source or not, we were still vulnerable all that time and nobody knew until now. You can't tell me right now that Heartbleed is for sure the _only_ bug in openSSL, because until now, nobody really looked that close (although I imagine some FOSS coders are making the time to double-check even as we speak).</div>
<div><br></div><div>Ultimately, even the best systems have the occasional hiccup. Hopefully Heartbleed will force us to implement better QC standards in FOSS, thereby making a great system even better.</div><div><br></div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 April 2014 23:33, Bob Jonkman <span dir="ltr"><<a href="mailto:bjonkman@sobac.com" target="_blank">bjonkman@sobac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cranky wrote:<br>
> Open Source is by definition safer for us, but only when the system<br>
> works. In this case, it failed us.<br>
<br>
On the contrary, Open Source worked exactly as it should. A bug was<br>
discovered in the source code, and patched by the community within days.<br>
<br>
Yes, it was a bit long between the bug creation and discovery. Do you<br>
think the bug would have been discovered and fixed sooner and faster if<br>
the source was closed? Considering that we were getting security updates<br>
in WinXP 13 years after its creation, Open Source isn't doing too badly.<br>
<br>
--Bob.<br>
<br>
<br>
On 14-04-20 10:08 PM, CrankyOldBugger wrote:<br>
> The NSA was taking advantage of bugs in openSSL for two years, yet<br>
> nobody noticed it until now. So it is indeed possible, as we have<br>
> just seen it happen.<br>
><br>
> Who knows what other bugs are out there.<br>
><br>
> Open Source is by definition safer for us, but only when the system<br>
> works. In this case, it failed us.<br>
><br>
><br>
> On 20 April 2014 19:28, unsolicited <<a href="mailto:unsolicited@swiz.ca">unsolicited@swiz.ca</a><br>
> <mailto:<a href="mailto:unsolicited@swiz.ca">unsolicited@swiz.ca</a>>> wrote:<br>
><br>
> The very nature of Open Source is such that that is not possible.<br>
><br>
> The source is free to see, use, modify, whatever.<br>
><br>
> And people do.<br>
><br>
> As I understand it, that is how Heartbleed was discovered - by code<br>
> review.<br>
><br>
> If any such back door were present, the community would refuse to use<br>
> it. The very act of putting in any such back door would thus be<br>
> self-defeating - nobody would use it, there would be no door, back or<br>
> otherwise, to enter.<br>
><br>
> People compile from source.<br>
><br>
> Source is retrieved from trusted repositories.<br>
><br>
> Repositories have gpg keys, things are checksummed.<br>
><br>
> You may upgrade with binaries, but those binaries have come from<br>
> trusted repositories.<br>
><br>
> Each combination has their own binary. Or they build their own from<br>
> trusted source, themselves.<br>
><br>
> Thus, many instances of running software around the world are<br>
> simultaneously and independently run, many of which are independently<br>
> compiled and built from the same source.<br>
><br>
> Depending upon the app, someone sticking something in in one place,<br>
> will either be immediately rejected, or rendered neuter by nothing<br>
> compatible with it. i.e. Send a request (for back door entry) would<br>
> be denied because nothing understands the request, or try to use an<br>
> algorithm that lets you derive a back door and it would be denied<br>
> because nobody would send you a key with this algorithm they do not<br>
> themselves have.<br>
><br>
> All of this web of trust is quite probably the single biggest<br>
> advantage (if the least understood by those new to computers) of<br>
> non-proprietary systems. When you update through your repository, you<br>
> KNOW it's good code. Not to say stuff doesn't creep in, or at least<br>
> try to. But any reasonably reputable repository, once such is<br>
> identified to them, shuts it down pretty damn quick.<br>
><br>
> OpenSSL, for example, is paid attention to really rather diligently.<br>
> The world depends upon it, so anything threatening it gets immediate<br>
> attention. (Even if it takes a while to trickle down to the end<br>
> user.)<br>
><br>
><br>
> On 14-04-20 01:59 PM, CrankyOldBugger wrote:<br>
><br>
> I would have to wonder, that if the NSA has some sort of back door or<br>
> trick to crack openSSL at 1024 bits, then they would probably have<br>
> the same backdoor or trick for 2048 or more bits. Just a thought,<br>
> I'm certainly not trying to put down the idea of using encryption!<br>
><br>
><br>
><br>
> On 20 April 2014 13:50, Jonathan Poole <<a href="mailto:jpoole@digitaljedi.ca">jpoole@digitaljedi.ca</a><br>
> <mailto:<a href="mailto:jpoole@digitaljedi.ca">jpoole@digitaljedi.ca</a>>> wrote:<br>
><br>
> Oh and of course, ensure you’re using an openssl version not<br>
> affected, or patched.<br>
><br>
> On Apr 20, 2014, at 1:47 PM, Jonathan Poole <<a href="mailto:jpoole@digitaljedi.ca">jpoole@digitaljedi.ca</a><br>
> <mailto:<a href="mailto:jpoole@digitaljedi.ca">jpoole@digitaljedi.ca</a>>> wrote:<br>
><br>
> How paranoid do you want to be?<br>
><br>
> At least 4096 IMHO, Computers are faster/stronger/ these days, higher<br>
> bits shouldn’t generate too much load decrypting.<br>
><br>
> if you want, generate a new cert everyday if you want.<br>
><br>
> *openssl genrsa -out ca.key 4096*<br>
><br>
> *openssl req -new -x509 -days 180 -key ca.key -out ca.crt* On Apr 20,<br>
> 2014, at 1:12 PM, Khalid Baheyeldin <<a href="mailto:kb@2bits.com">kb@2bits.com</a><br>
> <mailto:<a href="mailto:kb@2bits.com">kb@2bits.com</a>>> wrote:<br>
><br>
> Needless to say that recent events and government actions warrants<br>
> more paranoia ...<br>
><br>
> So, to that effect, what options should one use to have the SSH keys<br>
> stronger? How many bits? What options for ssh key gen should be<br>
> used?<br>
><br>
> And for SSL certificates, what options do you use to make the<br>
> certificates as strong as they can be? For example, I use the<br>
> following script for self signed certificates. How can this be<br>
> improved?<br>
><br>
> #!/bin/sh<br>
><br>
> KEY=server.key REQ=server.csr CRT=server.crt<br>
><br>
> cd ~/cert # Generate a key openssl genpkey -algorithm rsa -out $KEY #<br>
> Generate a certificate signing request openssl req -new -sha1 -nodes<br>
> -key $KEY -out $REQ # Create a self signed certificate openssl x509<br>
> -req -days 365 -in $REQ -signkey $KEY -out $CRT # Copy it to the<br>
> server cp $CRT /etc/ssl/certs cp $KEY /etc/ssl/private<br>
><br>
><br>
> -- Khalid M. Baheyeldin<br>
><br>
<br>
<br>_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
<br></blockquote></div><br></div>