SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts
James Sutherland
jas88 at cam.ac.uk
Thu Feb 10 07:49:11 GMT 2000
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.
More information about the samba-technical
mailing list