SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[James Sutherland]

On Thu, 10 Feb 2000, Luke Kenneth Casson Leighton wrote:

> > have big chunks of known plaintext, and access to the source code - in
> > which case, it would need to be a VERY tough algorithm (therefore subject
> 
> correc.   that's why i subscribed to coderpunks to ask their advice.  i
> have the algorithm i need.
>
> > - and you just end up with a privileged
> > private key file, which only your daemon may access, in order to control
> > access to the data files.
> 
> all absolutely corre and according to plan a)

You missed my point there. You still end up with an 0600 file which
controls access to all the passwords - but you also introduce the security
hole of anyone having access to the plaintext equivalent passwords WITHOUT
root access. OK, they are obfuscated - with a known algorithm, containing
lots of known plaintext.

More to the point, this would mean including strong crypto in the Samba
source code, thus subject to export controls.

Finally: Where are when do you decrypt the data? On load - meaning keeping
the entire SAM in (virtual) memory? Or on demand - meaning heavy CPU usage
when synchronising databases etc?

> > > or creating an equivalent of /etc/shadow
> > 
> > A good plan - t
> 
> plan b).

The one which has a lower performance cost, better scalability, more
efficient, better security...

> > here are reasons why this is the "normal" way of doing
> > things :-)
> 
> there are reasons why the mit krb inpl. also usess a syske-kile algoritm.
> and the openldap one.
> 
> plan a) is just as good as plan b).

> > > or just not explaining it, just getting on with it.
> > 
> > Oh dear... At this rate, MS will want to adopt your code. It'll have even
>  :)
> pffh!
> 
> > m
> 
> they'd have to release source to be absolutely the same.

They've done it before...


James.