Hi, Sorry for the late response... See inline...
-Loc -----Original Message----- From: Pierre Habouzit [mailto:madco...@debian.org] Sent: Saturday, January 31, 2009 2:35 PM To: Loc Ho Cc: Herbert Xu; linux-crypto@vger.kernel.org Subject: Re: [RFC] MPI module 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 ? [Loc Ho] Yes... We use this to test various algorithms supported by our hardware. 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 ? [Loc Ho] Yes... You will need an aead type algorithm that does what you want. Let say you want to process "DTLS" algorithm. Then provide a driver implementation for DTLS processing. From User Space, you would create this algorithm and operate on this algorithm over Linux CryptoAPI User Space interface. You might have to change slight in the User space interface code - try and see. 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). [Loc Ho] Yes... Unless you handle everything in the kernel (like IPSec), there is always a trade off. You could direct traffic to user space program and do all you processing and then inject back to the stack. 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. [Loc Ho] Not sure what you referring here... 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 madco...@debian.org OOO http://www.madism.org
