Re: Packages to remove from frozen

2000-03-09 Thread Paul Slootman
On Thu 09 Mar 2000, Jacob Kuntz wrote:

> isn't the problem here that the server is misrepresenting itself? a one bit
> difference may not make a less secure key, but it could quite possibly be an
> indication of some deception. i worry that altering the client to ignore
> this type of error will only open us up to attack, be it man-in-the-middle
> or otherwise.

Warning: my crypto knowledge is pretty poor.

Someone somewhere in this thread said that the problem was that the old
ssh could generate a key that had the MSbit off, and that was the cause
of these messages.  I'm now thinking: if the MSbit *MUST* be set, how
does that increase the security? N bits of key is no less secure than
N+1 bits where you know the value of one bit.  Isn't openssh simply
confused in this case?

I myself notice that openssh complains about half the time when
connecting to a random number of different hosts (I connect daily to a
random 5-10 systems out of a collection 700 hosts (each running ssh
1.2.17), which IMHO means the sample is quite random, but then
statistics lessons was a long time ago).


Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]   http://www.isdn4linux.de/



Re: Packages to remove from frozen

2000-03-09 Thread Jacob Kuntz
isn't the problem here that the server is misrepresenting itself? a one bit
difference may not make a less secure key, but it could quite possibly be an
indication of some deception. i worry that altering the client to ignore
this type of error will only open us up to attack, be it man-in-the-middle
or otherwise.

Ben Armstrong ([EMAIL PROTECTED]) wrote:
> On Thu, 9 Mar 2000, Junichi Uekawa wrote:
> > Isn't it that to decrypt 1024 key takes double the amount of
> > CPU time than decrypting 1023 key, as long as there is no other
> > method than brute-force method of trying every combination.
> > 
> > IMO It is a serious security issue, when the system is half as secure
> > and one is not notified. And the person is trying to use a ssh.
> 
> Where 'n' is a "reasonable" amount of time to crack a key using
> brute-force, doubling 'n' does not equate to doubling the security of your
> system.  At the most, you have caused the cracker the minor annoyance of
> having to wait twice as long for a result. 
> 
> Conversely, if '2n' is an "unreasonable" amount of time to crack a key
> using brute-force, halving it to 'n' does not equate to halving the
> security of your system.
> 
> In other words, I rely on my ssh keys being several orders of magnitude
> more difficult to crack than weaker crypto that is crackable in a
> "reasonable" amount of time by brute force.  Whether the keys are 1023 bit
> or 1024 bit is irrelevant.  Both accomplish this goal.
> 
> Ben
> -- 
> nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
> Debian  http://www.debian.org   [EMAIL PROTECTED]
> [ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
> [ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
(jacob kuntz)[EMAIL PROTECTED] [EMAIL 
PROTECTED],underworld}.net
(megabite systems)   "think free speech, not free beer."



Re: Packages to remove from frozen

2000-03-08 Thread Ben Armstrong
On Thu, 9 Mar 2000, Junichi Uekawa wrote:
> Isn't it that to decrypt 1024 key takes double the amount of
> CPU time than decrypting 1023 key, as long as there is no other
> method than brute-force method of trying every combination.
> 
> IMO It is a serious security issue, when the system is half as secure
> and one is not notified. And the person is trying to use a ssh.

Where 'n' is a "reasonable" amount of time to crack a key using
brute-force, doubling 'n' does not equate to doubling the security of your
system.  At the most, you have caused the cracker the minor annoyance of
having to wait twice as long for a result. 

Conversely, if '2n' is an "unreasonable" amount of time to crack a key
using brute-force, halving it to 'n' does not equate to halving the
security of your system.

In other words, I rely on my ssh keys being several orders of magnitude
more difficult to crack than weaker crypto that is crackable in a
"reasonable" amount of time by brute force.  Whether the keys are 1023 bit
or 1024 bit is irrelevant.  Both accomplish this goal.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]




Re: Packages to remove from frozen

2000-03-08 Thread Junichi Uekawa
In Wed, 8 Mar 2000 11:10:11 -0500, de profundis Michael Stone <[EMAIL 
PROTECTED]> cum veritas scribat

mstone> Are you really convinced that the security of a 1023 bit key is so much
mstone> worse than the security of a 1024 bit key that any amount of effort
mstone> necessary to transition to a new 1024 bit key is justified? In the

Isn't it that to decrypt 1024 key takes double the amount of
CPU time than decrypting 1023 key, as long as there is no other
method than brute-force method of trying every combination.

IMO It is a serious security issue, when the system is half as secure
and one is not notified. And the person is trying to use a ssh.



---
dancer, a.k.a. Junichi Uekawa
 Dept. of Knowledge Engineering and Computer Science, Doshisha University.
... Long Live Free Software, LIBERTAS OMNI VINCIT.



Re: Packages to remove from frozen

2000-03-08 Thread Michael Stone
On Wed, Mar 08, 2000 at 09:18:06AM -0500, Branden Robinson wrote:
> Use the Source, Luke.  Quit whining and start coding.

Why? On hosts where this is an issue, f-secure's ssh does the job just
fine. (Not to mention that I don't live in a free country and can't work
on ssh...)

-- 
Mike Stone


pgpQc9EIx2b7L.pgp
Description: PGP signature


Re: Packages to remove from frozen

2000-03-08 Thread Michael Stone
On Wed, Mar 08, 2000 at 08:56:34AM -0600, Nathan E Norman wrote:
> Eh, well, it is correct[1] behavior to toss out an error message in this
> case since it's notifying you of a *security* problem.  In fact, it's
> telling you that the server key is half as secure as the server claims
> it is.

But you *don't* get informed about what the server claims the key is
unless you request verbosity. This isn't about displaying wrong info
versus displaying right info. This is about displaying extra information
for no reason. If the notice that the server was offering an invalid key
length came in verbose mode, that would be great; if you got a warning
when you first accept the key, that would be useful. What does seeing the
message at every login buy you?

> If you and your users don't care about security then I'm sure the
> error is a real pain in the ass.  Of course, if security isn't an
> issue then you really don't need to use ssh at all.

Are you really convinced that the security of a 1023 bit key is so much
worse than the security of a 1024 bit key that any amount of effort
necessary to transition to a new 1024 bit key is justified? In the
overall scheme of things, that one bit is *not* a high-priority security
problem. Changing keys around and getting users into the habit of
replacing host keys is a *bigger* security problem than that stupid bit.

-- 
Mike Stone


pgpOaT7MmEkRB.pgp
Description: PGP signature


Re: Packages to remove from frozen

2000-03-08 Thread Nathan E Norman
On Tue, Mar 07, 2000 at 11:26:12PM -0500, Michael Stone wrote:
> On Tue, Mar 07, 2000 at 03:13:36PM -0800, Joey Hess wrote:
> > Michael Stone wrote:
> > > Not very backward-compatible, is it? In some environments it's desirable
> > > to have the software behave the same on every platform; even if it's
> > > buggy, the bugs need to be consistent.
> > 
> > This is linux. We break backwards compatability if we have to do do things
> > *right*.
> 
> How is it right to spit out an error message on every connection that
> adds nothing to most people's use of the product? Especially when there
> exists a verbose mode for people who want lots of gory details about the
> efficacy of their connection? SSH doesn't tell me the key length of
> connections *except* in this one case--which is not consistent, and
> which is not unambiguously "*right*" behavior.

Eh, well, it is correct[1] behavior to toss out an error message in this
case since it's notifying you of a *security* problem.  In fact, it's
telling you that the server key is half as secure as the server claims
it is.

If you and your users don't care about security then I'm sure the
error is a real pain in the ass.  Of course, if security isn't an
issue then you really don't need to use ssh at all.

Generally you complain about issues that have relevance.  I think
you've missed on this one.

Cheers,

-- 
Nathan Norman "Eschew Obfuscation"  Network Engineer
GPG Key ID 1024D/51F98BB7http://home.midco.net/~nnorman/
Key fingerprint = C5F4 A147 416C E0BF AB73  8BEF F0C8 255C 51F9 8BB7

[1] "Right" describes a direction, specifically the one opposite
"left".


pgpFY4jPH9kRJ.pgp
Description: PGP signature


Re: Packages to remove from frozen

2000-03-08 Thread Branden Robinson
On Tue, Mar 07, 2000 at 11:26:12PM -0500, Michael Stone wrote:
> How is it right to spit out an error message on every connection that
> adds nothing to most people's use of the product? Especially when there
> exists a verbose mode for people who want lots of gory details about the
> efficacy of their connection? SSH doesn't tell me the key length of
> connections *except* in this one case--which is not consistent, and
> which is not unambiguously "*right*" behavior.

I disagree with your analysis, but nevertheless...

Use the Source, Luke.  Quit whining and start coding.

-- 
G. Branden Robinson|A celibate clergy is an especially good
Debian GNU/Linux   |idea, because it tends to suppress any
[EMAIL PROTECTED] |hereditary propensity toward fanaticism.
roger.ecn.purdue.edu/~branden/ |-- Carl Sagan


pgpZfjGUNDsxY.pgp
Description: PGP signature