From owner-freebsd-hackers Mon Aug 16 10:26:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id CB2AA14D1D; Mon, 16 Aug 1999 10:26:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BB6F61CD892; Mon, 16 Aug 1999 10:26:57 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Mon, 16 Aug 1999 10:26:57 -0700 (PDT) From: Kris Kennaway To: nsayer@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? In-Reply-To: <37B5E8CD.EBEFACDB@quack.kfu.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry for not responding to this earlier, I missed it in my inbox. On Sat, 14 Aug 1999, Nick Sayer wrote: > > Where do you store the keys, or do you generate them dynamically? The > > latter would take time to verify primality. > > If by "keys" you mean the DH generator and such, they are constants in > the code at present. It is possible to extend the protocol in such a > way as to pass them from server to client, but at present it does not > do this. Having them be constant does not significantly weaken DH. If > they weren't, you'd have to pass them from the server at session > start. Are you sure about this? Having constant p, g, x and y for every telnet client and server surely makes it much easier to attack? In theory you could probably pregenerate all of the arithmetic. > > Because it does not interoperate with legacy servers over NIS? Any other > > reasons? > > If you're saying that you're going to have a new format of the second > field of the master passwd file ($3$[^:]* ?), then I suppose the only > other one left is having to convert legacy password files and manage > the N and g values that SRP requires. You'll have to fix things that > add users to have them default to the new scheme. Probably a PAM module which rehashes passwords into the new format. I'd expect one such module already exists. So you'd set up the PAM module to run as part of the login module stack and tell libcrypt that the user gets a default password of SRP. Alternatively, expire all their passwords and when they pick a new one it will be SRP. > And don't sniff at breaking NIS. Most sites I deal with use it. And I > don't know of any site that uses NIS that isn't heterogenous, which > requires the legacy password format. As David Wolfskill explained this should be solvable. > > In my scheme I distribute these as part of the password "hash". N and g > > are both public values known to both client and server(s). > > SRP has them in configuration files. They have to be set up. Yes, on the server. This is a non-issue. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message