Re: PBKDF2 support in the linux kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2018-05-24 at 20:42 -0400, Theodore Y. Ts'o wrote:
> On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote:
> > 
> > But seriously, how is it a fault of the 'random person on the
> > mailing list'
> > that AF_ALG exists and is being used for its (seemingly intended)
> > purpose?
> > 
> > I'm not really here to criticize or judge the past.  AF_ALG exists
> > now. It
> > is being used.  Can we just make it better?  Or are we going to
> > whinge at
> > every user that tries to use (and improve) kernel features that
> > (some)
> > people disagree with because it can 'compromise' kernel security?
> 
> Another point of view is that it was arguably a mistake, and we
> shouldn't make it worse.
> 
> > > Also, if speed isn't a worry, why not just a single software-only
> > > implementation of SHA1, and be done with it?  It's what I did in
> > > e2fsprogs for e4crypt.
> > 
> > If things were that simple, we would definitely not be having this
> > exchange.
> > Lets just say we use just about every feature that crypto subsystem
> > provides
> > in some way.
> 
> What I'm saying here is if you need to code PBPDF2 in user-space, it
> _really_ isn't hard.  I've done it.  It's less than 7k of source code
> to implement SHA512:
> 
> https://ghit.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs
> /sha256.c
> 
> and then less than 50 lines of code to implement PBPDF2 (I didn't
> even
> bother putting in a library such as libext2fs):
> 
> https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/misc/e4cryp
> t.c#n405
> 
> This is all you would need to do if we don't put PBPDF2 in the
> kernel.
> Is it really that onerous?
> 
> If you don't want to use some crypto library, I don't blame you --- I
> just grabbed the code and dropped it into e2fsprogs; so I understand
> that POV.  And so if you want to keep using AF_ALG, we made a
> mistake,
> created an attractive nuisance, and we have to support it forever.
> Fine.  But we don't have to add more _stuff_ into the kernel....

Because having millions of copies of SHA1, MD5, and SHA2 and .... in
millions of applications is the best thing. 

Now that's something I would call laziness - just copy the code and do
not care about doing the proper decision which crypto library to use.

LOL

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux