All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Cc: Nikos Mavrogiannopoulos <nmav@gnutls.org>,
	linux-crypto@vger.kernel.org,
	Nico Erfurth <nico.erfurth@viprinet.com>,
	Simon Kissel <simon.kissel@viprinet.com>
Subject: Re: RFC: kcrypto - (yet another) user space interface
Date: Fri, 11 Jun 2010 12:51:34 +0200	[thread overview]
Message-ID: <20100611105142.230FC4CD45@orbit.nwl.cc> (raw)
In-Reply-To: <20100611090856.GA31092@Chamillionaire.breakpoint.cc>

Hey,

Seems like I'm stabbing into open wounds. :) First of all, thanks a lot
for your comments.

On Fri, Jun 11, 2010 at 11:08:56AM +0200, Sebastian Andrzej Siewior wrote:
> * Nikos Mavrogiannopoulos | 2010-06-11 09:47:15 [+0200]:
> 
> >Sebastian Andrzej Siewior wrote:
> >> * Phil Sutter | 2010-06-10 20:22:29 [+0200]:
> >
> >The problem with right or wrong is that they are only known afterwards.
> >For me the right way to go is _to go_. I can see discussions in this
> >least, years ago on talks about the "perfect" userspace crypto api and
> >rejections implementations because they are not perfect enough. I don't
> >believe there is such thing as a perfect crypto api. Other operating
> >systems have a userspace crypto API (maybe not perfect) but linux
> >hasn't. I don't think this is the way to go.
> 
> Phil asked me for my opinion and he got it. The fundumention problems
> from what I've seen was the interface:
> - kernel structs which are exposed to userland which limit the
>   parameters. For instance the iv was limited to 16 bytes while we have
>   allready algos with a much longer iv.
> - the interface was using write()/poll()/read() and get_user_pages(). I
>   pointed out Herbert's opinion about this and the alternative. So this
>   _was_ allready discsussed.

For me, this project is a rather pragmatical one - this just needs to
get done, and it has to be just perfect enough so my employer finds it
usable. Nice to have if I happen to create the perfect CryptoAPI user
space interface ever (yeah, right ...) but this is unlikely to happen.
For me it's enough to first get the concept right and next make it
stable and functional. After that I'm sure we all can tell better if
it's worth pushing it towards the kernel or leave it as (yet another)
niche product.

Greetings, Phil

  reply	other threads:[~2010-06-11 10:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-10 18:22 RFC: kcrypto - (yet another) user space interface Phil Sutter
2010-06-10 21:14 ` Sebastian Andrzej Siewior
2010-06-11  7:47   ` Nikos Mavrogiannopoulos
2010-06-11  9:08     ` Sebastian Andrzej Siewior
2010-06-11 10:51       ` Phil Sutter [this message]
2010-06-11 17:00   ` Phil Sutter
2010-06-11 17:00   ` Phil Sutter
2010-06-12 16:40 ` Uri Simchoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100611105142.230FC4CD45@orbit.nwl.cc \
    --to=phil@nwl.cc \
    --cc=linux-crypto@vger.kernel.org \
    --cc=nico.erfurth@viprinet.com \
    --cc=nmav@gnutls.org \
    --cc=sebastian@breakpoint.cc \
    --cc=simon.kissel@viprinet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.