> On Mon, 14 Jan 2008, Dennis Clarke wrote:
>
>       hi Dennis,
>
>>I use SSH daily and on just about everything I own. I do not wear a
>> tin-foil
>>hat but I do use aes256-cbc ( or similar ) as my Cipher of choice and I
>>generally configure servers to *only* accept aes256-cbc ( or similar ). I
>>also tend to set KeyRegenerationInterval to 300 secs and I do not allow the
>>use of a cleartext password.
>
>       this is this one:
>
>       6617424 aes192-cbc/aes256-cbc support is missing from ssh/sshd
>
>       however, using anything else than aes128 is just burning
>       CPU cycles. A nice paper about that was written in 1996
>       and think it still stands:
>
>       http://www.schneier.com/paper-keylength.pdf

Almost anything with Bruce Schneier's name on it is taken as papal decree
and even if we dismiss the names over the title ( hollywood slang ) we can
not dismiss the math. However, I beg you bear with me here. I have pesonally
witnessed man land on the moon. Via television of course but I was happy to
be plunked in front of a black and white television at the time. That would
be about the same time that people were probably having similar arguments
about the strength of 56-bit DES and the need for a shorter key such that
government agencies can decrypt if needed.

CPU cycles are cheap. So cheap in fact that I expect the ordinary home
computer to be essentially free with a support contract this year. Feel free
to see my thoughts on that at

    http://www.blastwave.org/dclarke/blog/?q=node/99

Cell phones are essentially free. So are digital watches and so too we shall
see the fast multi-gigahertz clock cyle frequency home computer. With a
contract of course. So now that all those unbreakable and impossible feats
like breaking the sound barrier and landing on the moon are out of the way
we can only hope to see 128-bit key length ciphers cracked in our lifetime.
It probably won't happen with brute force or even with large distributed
networks like BOINC cracking away madly on a billion computers. It will most
likely be a quantum leap, a digital shift in thinking like, well just like
quantum computing that will shatter previous notions of what we call
impossible.

It is not impossible at all. Merely improbable. Even with current
techniques. So improbable because ( 2^128 - 1 ) =
340282366920938463463374607431768211455 is a staggeringly large number. Even
Mathematica takes a pause to factor a number that has prime factors in that
scale. But it can be done. Like landing on the moon.

I have this theory that we need crypto ciphers that are computationally
expensive and based not on the difficulty of prime factorization but on the
unpredictability of stochastic processes. Possibly even optical encryption
using signal processing techniques. But, that is just *my theory* and it
probably isn't worth the napkin it was first scribbled on :

  http://www.blastwave.org/dclarke/stuff/NRP/index.html

But .. I may be guessing.

>>The SunSSH version is this :
>>
>>$ /usr/bin/ssh -V
>>Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
>>
>>I do not know what that means.
>
>       SunSSH 1.1. Sun forked OpenSSH, twice basically. The second fork was
> from OpenSSH 3.5p1. And it's documented here:
>
>       http://www.opensolaris.org/os/community/security/projects/SSH/

I'll give that a close read. Sometimes a fork is a good thing. Sometimes not
so good. The real question is why?  I have to go read first before stumbling
about.

>># /usr/bin/ssh -V
>>Sun_SSH_1.2, SSH protocols 1.5/2.0, OpenSSL 0x0090801f
>># /usr/bin/ssh -2 -4 -c aes256-cbc mars
>>Unknown cipher type 'aes256-cbc'
>
>       yes, a newer version of SunSSH. The increased version number means
> that a new compatibility flag was added. Again, it's documented on
> OpenSolaris SSH page.

right .. I get the picture. I have to RTFM ( Read The Full Manual )

  :-)

>>So the short answer here is that I don't know what the Sun implementation
>> of
>>SSH is really but it seems to be NOT what we see at the source site. So
>> that
>>really is the only reason why I tend to run the packages built on reference
>>servers that I trust and with source code drawn directly from the well.
>>
>>Am I wrong to think this way ?
>
>       well, I don't really think there is a need for that (and I gave an
> example the last time that being conservative might mean being more secure,
> not less) but I understand that you might want to run latest OpenSSH and
> nothing else.

Simply "feeling" correct is not the same is actually "being" correct and in
the case of encryption there are strict mathematical processes that render
feelings to be of no consequence.  If ya know what I mean.

Dennis

_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to