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]

Message-ID: <38b2ab8a0704130630v4c840bd1w19f2a239f86a93b@mail.gmail.com>
Date:	Fri, 13 Apr 2007 15:30:38 +0200
From:	"Francis Moreau" <francis.moro@...il.com>
To:	"Helge Hafting" <helge.hafting@...el.hist.no>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [CRYPTO] is it really optimized ?

Hi,

On 4/13/07, Helge Hafting <helge.hafting@...el.hist.no> wrote:
> Francis Moreau wrote:
> > So is this interpretation right ? If so wouldn't it be appropriate to
> > introduce a mechanism to reserve this AES hardware for a special
> > purpose (filesystem encryptions) and thus make it as fast as possible
> > ?
> >
> Would this really help?
> When reading/writing files, most of the time is i/o-wait, isn't it?
>

Well some systems, specially embedded ones, don't use hard drives for
mass storage purposes but rather MTD like flashes...

> Reserving the device exclusively seems excessive. How about
> a quick test to see if someone else have been using it since
> the last time your crypto-fs used it?  If nobody else used it, then
> you don't need to reset they key and so on.
>

You would spend the same time to make the test as loading the key...

> If nobody else is using the AES controller, you get the same speed
> as with a reservation.

I don't think this is right. AES hardware can do a block encryption in
a very few cycles. If you copy the key or test the key to see if it
has changed as you proposed, then you basically increase the execution
time by a factor 2 or 3...

> If something else is using AES then it won't be
> as fast, but then the AES controller have been used for other useful
> work as well.  Other parts of the kernel surely won't use it just for
> fun. :-)

You said it: others parts of the kernel are unlikely to use it. So why
not optimizing the common case ?

Crypto core already seems to implement a priority mechanism. But I
don't think I'm able to say "I'd like to use this algo for encrypting
filesystems. If another part of the kernel wants to use this algo then
give it the generic one". This choice seems really to depend on the
system the kernel is running.
-- 
Francis
-
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/