[kwlug-disc] Stronger SSH keys and SSL certificates

[unsolicited]

Your not getting what I said - the NSA CANNOT have a back door. It would 
not survive in the code base.

Last I saw, there was denial that NSA had it, etc. Let's stop using that.

Encryption length has nothing to do with ability to read mail, so please 
stop that FUD.

Heartbleed MAY let you read some traffic that passes through a server, 
IF you're in it at the time to request the hearbeat, it MAY let you 
sleuth out some passwords - IF they went through. If your e-mail is not 
on that server, there is no e-mail to read. If you didn't read e-mail, 
there is no e-mail password to read. It may reveal a password that they 
then connect to the appropriate server and they MAY go to that server 
and dig through stuff.

It does NOT let you go from this server to another server and start 
digging. Each SSL session exchanges new keys that are based upon 
certificates and unique to each session. Having the base keys would let 
you spoof that you are the server you say you are, but a lot of stars 
have to align for anything useful to come of it. And you have to be the 
biggest target in the neighbourhood to be worth going after in the first 
place. And although big, resources are scarce.

In essence, Heartbleed and SSL encryption keys are distinct beasties. 
Heartbleed is a bug resulting from a not extremely experienced coder 
coding mistake that wasn't caught during peer review. Free code, free 
peer reviewed, and like most open source, inadequately funded. From your 
article, posted New Year's Eve - like anything then is ever likely to be 
adequately reviewed.

That we get anywhere at all is bizarre, a testament to the community of 
the world, and so far ahead of commercial proprietary schemes as to not 
be in the same ballpark.

No code is bug free. There are, nor ever were, any guarantees.

Heartbleed will not likely implement better QC standards in FOSS. See 
free. If you want to see such, start contributing to the ssl code review.

What? Can't? Not qualified? ... so why would you think anyone else is? 
Or would?  Or the world starts paying people to do such. But ... it then 
wouldn't be FOSS.

It is what it is. It's the best out there. It's pretty damn good. And 
beats anything proprietary - that's why proprietary systems use it.

There is no back door. Encryption key length is a different beastie.

Let's move on.

On 14-04-21 12:40 AM, CrankyOldBugger wrote:
> 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 (
> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html).
>   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.
>
> 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).
>
> 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.
>
>
>
>
>
> On 20 April 2014 23:33, Bob Jonkman <bjonkman at sobac.com> wrote:
>
>> Cranky wrote:
>>> Open Source is by definition safer for us, but only when the system
>>> works.  In this case, it failed us.
>>
>> On the contrary, Open Source worked exactly as it should. A bug was
>> discovered in the source code, and patched by the community within days.
>>
>> Yes, it was a bit long between the bug creation and discovery. Do you
>> think the bug would have been discovered and fixed sooner and faster if
>> the source was closed? Considering that we were getting security updates
>> in WinXP 13 years after its creation, Open Source isn't doing too badly.
>>
>> --Bob.
>>
>>
>> On 14-04-20 10:08 PM, CrankyOldBugger wrote:
>>> The NSA was taking advantage of bugs in openSSL for two years, yet
>>> nobody noticed it until now.  So it is indeed possible, as we have
>>> just seen it happen.
>>>
>>> Who knows what other bugs are out there.
>>>
>>> Open Source is by definition safer for us, but only when the system
>>> works.  In this case, it failed us.
>>>
>>>
>>> On 20 April 2014 19:28, unsolicited <unsolicited at swiz.ca
>>> <mailto:unsolicited at swiz.ca>> wrote:
>>>
>>> The very nature of Open Source is such that that is not possible.
>>>
>>> The source is free to see, use, modify, whatever.
>>>
>>> And people do.
>>>
>>> As I understand it, that is how Heartbleed was discovered - by code
>>> review.
>>>
>>> If any such back door were present, the community would refuse to use
>>> it. The very act of putting in any such back door would thus be
>>> self-defeating - nobody would use it, there would be no door, back or
>>> otherwise, to enter.
>>>
>>> People compile from source.
>>>
>>> Source is retrieved from trusted repositories.
>>>
>>> Repositories have gpg keys, things are checksummed.
>>>
>>> You may upgrade with binaries, but those binaries have come from
>>> trusted repositories.
>>>
>>> Each combination has their own binary. Or they build their own from
>>> trusted source, themselves.
>>>
>>> Thus, many instances of running software around the world are
>>> simultaneously and independently run, many of which are independently
>>> compiled and built from the same source.
>>>
>>> Depending upon the app, someone sticking something in in one place,
>>> will either be immediately rejected, or rendered neuter by nothing
>>> compatible with it. i.e. Send a request (for back door entry) would
>>> be denied because nothing understands the request, or try to use an
>>> algorithm that lets you derive a back door and it would be denied
>>> because nobody would send you a key with this algorithm they do not
>>> themselves have.
>>>
>>> All of this web of trust is quite probably the single biggest
>>> advantage (if the least understood by those new to computers) of
>>> non-proprietary systems. When you update through your repository, you
>>> KNOW it's good code. Not to say stuff doesn't creep in, or at least
>>> try to. But any reasonably reputable repository, once such is
>>> identified to them, shuts it down pretty damn quick.
>>>
>>> OpenSSL, for example, is paid attention to really rather diligently.
>>> The world depends upon it, so anything threatening it gets immediate
>>> attention. (Even if it takes a while to trickle down to the end
>>> user.)
>>>
>>>
>>> On 14-04-20 01:59 PM, CrankyOldBugger wrote:
>>>
>>> I would have to wonder, that if the NSA has some sort of back door or
>>> trick to crack openSSL at 1024 bits, then they would probably have
>>> the same backdoor or trick for 2048 or more bits.  Just a thought,
>>> I'm certainly not trying to put down the idea of using encryption!
>>>
>>>
>>>
>>> On 20 April 2014 13:50, Jonathan Poole <jpoole at digitaljedi.ca
>>> <mailto:jpoole at digitaljedi.ca>> wrote:
>>>
>>> Oh and of course, ensure you’re using an openssl version not
>>> affected, or patched.
>>>
>>> On Apr 20, 2014, at 1:47 PM, Jonathan Poole <jpoole at digitaljedi.ca
>>> <mailto:jpoole at digitaljedi.ca>> wrote:
>>>
>>> How paranoid do you want to be?
>>>
>>> At least 4096 IMHO, Computers are faster/stronger/ these days, higher
>>> bits shouldn’t generate too much load decrypting.
>>>
>>> if you want, generate a new cert everyday if you want.
>>>
>>> *openssl genrsa -out ca.key 4096*
>>>
>>> *openssl req -new -x509 -days 180 -key ca.key -out ca.crt* On Apr 20,
>>> 2014, at 1:12 PM, Khalid Baheyeldin <kb at 2bits.com
>>> <mailto:kb at 2bits.com>> wrote:
>>>
>>> Needless to say that recent events and government actions warrants
>>> more paranoia ...
>>>
>>> So, to that effect, what options should one use to have the SSH keys
>>> stronger? How many bits? What options for ssh key gen should be
>>> used?
>>>
>>> And for SSL certificates, what options do you use to make the
>>> certificates as strong as they can be? For example, I use the
>>> following script for self signed certificates. How can this be
>>> improved?
>>>
>>> #!/bin/sh
>>>
>>> KEY=server.key REQ=server.csr CRT=server.crt
>>>
>>> cd ~/cert # Generate a key openssl genpkey -algorithm rsa -out $KEY #
>>> Generate a certificate signing request openssl req -new -sha1 -nodes
>>> -key $KEY -out $REQ # Create a self signed certificate openssl x509
>>> -req -days 365 -in $REQ -signkey $KEY -out $CRT # Copy it to the
>>> server cp $CRT /etc/ssl/certs cp $KEY /etc/ssl/private
>>>
>>>
>>> -- Khalid M. Baheyeldin
>>>
>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>>
>
>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>