[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto-vger
Subject:    Re: [RFC] MPI module
From:       Pierre Habouzit <madcoder () debian ! org>
Date:       2009-01-31 22:34:55
Message-ID: 20090131223455.GA18560 () artemis ! corp
[Download RAW message or body]

On Fri, Jan 30, 2009 at 06:54:16PM +0000, Loc Ho wrote:
> Hi,
> 
> I would like to add that you can even handle the TLS/DTLS/SSL packet
> formation in the kernel as well if you provide an algorithms that does
> just that. Right now, most user just use the kernel for the hashing
> and cipher parts. There is no reason that the current framework cannot
> handle processing the full packet in hardware. All you need is to
> create another algorithm name that is aead type. Then, from user space
> (using Linux CryptoAPI user space interface) creates that algorithms.
> The underlying CryptoAPI will call the appropriate function that
> provided by your driver and the result of the operation will be an
> TLS/DTLS/SSL packet formation. 

Okay, this sounds nifty, though I'm not 100% sure I follow you. When
you're talking about "Linux CryptoAPI userspace interface" are you
talking about things like cryptodev[1] that aren't (AFAICT) merged into
the mainline kernel ?

Or do you mean that I should write a new aead algorithm, plus provide a
way (probably ioctl ?) to "activate" that algorithm on my socket once
user-land has negociated the ciphers and similar stuff ?

Also, this has the drawback, unless I'm mistaken, that the program using
the socket has to be aware it's using SSL/TLS/DTLS. Of course, when
writing something doing SMTP with STARTTLS it has to be somehow aware of
the SSL layer, since the handshake is delayed. But it would be quite sad
to be unable to secure a socket without the user noticing it at any
time. For example, it would be quite nifty to do through iptables
something that would redirect a given port to another one and adding SSL
at the same time (e.g. redirect 1.2.3.4:443 to 127.0.0.1:80 _and_ adding
SSL on the top).


It makes sense to want to put the handshakes and negociations in
user-space, and the system-wide ssl daemon for that task makes sense to
me. So I was basically trying to figure out a clean way to "redirect"
all non data SSL/TLS payloads (IOW handshakes and stuff like that) to
the daemon, and the rest to the actual socket/application[2]. So either
I'm wrong about what I'm trying to design, or I miss something in how
your hint can help me.

Anyways, I would be delighted if you can give me more details about what
you meant :)




  [1] http://www.logix.cz/michal/devel/cryptodev/

  [2] Which rises issues since unlike IPSec we have some programs
      _aware_ that they want to use SSL: it's okay to _have_ to write
      configuration for the system-wide daemon if you're securing
      something behind the original program's back. But I want that
      programs are still able to chose their certificate themselves and
      stuff like that, and it's somehow "hard" (as in racy and/or
      insecure) that a given program creates a socket, mark it as secure
      (e.g. using a setsockopt) and uploading informations about that
      new socket to the regulatory daemon (in the sense that anyone can
      claim that it possess that given socket, only the kernel really
      knows about it).  But I assume those issues can be resolved later
      once I've accustomed myself with the kernel crypto a bit more.

-- 
 ·O ·  Pierre Habouzit
 · ·O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[Attachment #3 (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]