linux-kernel - Re: [CRYPTO] is it really optimized ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Apr 2007 19:57:25 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Francis Moreau <francis.moro@...il.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	helge.hafting@...el.hist.no, linux-kernel@...r.kernel.org,
	linux-crypto@...r.kernel.org
Subject: Re: [CRYPTO] is it really optimized ?

On Tue, Apr 17, 2007 at 05:34:12PM +0200, Francis Moreau (francis.moro@...il.com) wrote:
> >Preventing anyone from using the module is incorrect.
> >How will you handle the case when you have only one algo registered and
> >it will be exclusively used by ecryptfs?
> >
> 
> As I tried to explain, in that case the admin must load the module
> without the exclusive flag.

If there are another users, then flag should not be set.
If there are no another users, your code already has exclusive access.
One can not know if there will be any additional users at all (consider
the case when new encrypted block device or ipsec negotiation started
some time after module was loaded).

> >Herbert proposes to register _second_ algo (say aes-generic(prio_100)
> >and aes_for_ecryptfs(prio_1)) with lower prio, so generic access will
> >never try to catch aes_for_ecryptfs, but your code still can access it
> >using full name.
> >
> 
> yes but my worries with this approach is that nothing prevent an admin
> to load others modules that will use aes_for_ecryptfs. And an admin is
> not always aware about a module implementation.

Some module is not allowed to force such restrictions, since it does not
know if there are other users or other algorithms.
You can call your algo with private company name hashed with author's
birtday, so no one in the world will be able to request such algo.
Actually its name can be read from /proc/crypto, but that is another
story.

> Thanks
> -- 
> Francis

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/