User: Password:
|
|
Subscribe / Log in / New account

A netlink-based user-space crypto API

A netlink-based user-space crypto API

Posted Oct 21, 2010 6:16 UTC (Thu) by neilbrown (subscriber, #359)
Parent article: A netlink-based user-space crypto API

I must say I'm not a big fan of sockets or netlink. You cannot access them with shell scripts...

I much prefer the filesystem model.

{ cat myfile &>0 ; read hash ; } <> /random-mountpoint/crypto/hash/sha1

So the name of the algorithm in passed as part of the file name, the content is written to the file descriptor. The hash is read from that same filedescriptor. The hash state is stored attached to the 'struct file'. See "Transaction based IO" in fs/libfs.c. It would need to be extended to work with writing a large file, but the concept is sound.

For encrypting.. using the same 'fd' for both read and write is problematic in a way that it isn't (so much) for the above. The original (Unix 6) pipe syscall returned only one fd which you could read from and write to. One problem with that was that it can be awkward to detect when the 'write' end has been closed (so the read end should get EOF), as there is no distinction between the two. If you happen to have two processes with the 'read' end open you never see EOF.

If we can either ignore that or work around it, then
/mountpoint/crypto/cypher/$direction/$cyphertype/$key/$iv
is a promising file name to write to/ read from, except that there is a risk that the key would get stuck in the dcache and appear in /proc/$N/fd/$FD. I'm sure that is solvable though. The key would be HEX or BASE64 encoded of course.

The need to multiplex cyphertext and MAC is certainly a complication. I suspect there was a reason Herbert suggested 2 sockets rather than a simple multiplexing scheme. Without knowing that reason it is pointless trying to refine the design.

If it was to be done with sockets, it would seem to make much more sense to use 'socketpair(AF_ALG, SOCK_STREAM, ....)' rather than the sockets + accept model. Then you have distinct 'read' and 'write' ends. I would also use MSG_OOB to send the MAC beside the cyphertext rather than having two separate streams (not that I am a big fan of MSG_OOB, but it does seem to be a shoe that fits).


(Log in to post comments)

A netlink-based user-space crypto API

Posted Oct 21, 2010 14:23 UTC (Thu) by ken (subscriber, #625) [Link]

I have to confess that I do not understand what problem the open() ioctl() interface have that the socket() setsockopt() bind() accept() solves.

To me it looks like you just transform magic ioctl number into magic socket options and magic sendmsg() commands.

where is the benefit over /dev/crypto ??

A netlink-based user-space crypto API

Posted Nov 1, 2010 4:49 UTC (Mon) by kevinm (guest, #69913) [Link]

The advantage that the sockets API has over ioctl is that the former provides a single, standard, already implemented and tested method of marshalling and unmarshalling parameters kernel-side.

The fundamental problem of the ioctl interface is that every implementer of the interface must re-implement that parameter marshalling - for every arch. There are plenty of ioctl()s that *still* don't work properly for IA32 callers on x86-64 arch.

No way to access sockets from a shell script?

Posted Oct 21, 2010 15:04 UTC (Thu) by rvfh (subscriber, #31018) [Link]

What about netcat?

No way to access sockets from a shell script?

Posted Oct 21, 2010 15:12 UTC (Thu) by jengelh (subscriber, #33263) [Link]

What you would want is socat, anyway.

No way to access sockets from a shell script?

Posted Oct 21, 2010 16:29 UTC (Thu) by nye (guest, #51576) [Link]

HFS. I've never seen socat before, but from reading the manpage I'm pretty certain it must have the option to Dominate All Humans, if only I can figure out the right command line arguments.

No way to access sockets from a shell script?

Posted Oct 28, 2010 19:11 UTC (Thu) by oak (guest, #2786) [Link]

I mistyped that a few years ago and the operation seems to be non-reverseable. Sorry.

Hmmm. On second thought, I would assume socat author to have tested all the documented options. Maybe I used it with the --simulate option after all.

(That could also explain the dancing ping elephants and Jumbo frame's enormous flapping ears...)

No way to access sockets from a shell script?

Posted Oct 22, 2010 1:42 UTC (Fri) by neilbrown (subscriber, #359) [Link]

While I'm sure socat is an absolutely awesome program, I'm guessing it isn't precognitive, and so cannot support new address families and socket options until someone goes to the trouble of coding them in.

With suitably chosen file names, no such extra coding for the shell is needed.

A netlink-based user-space crypto API

Posted Oct 21, 2010 15:13 UTC (Thu) by jengelh (subscriber, #33263) [Link]

I would prefer not to have the IV in the filename, for that would potentially be visible in ps output.

A netlink-based user-space crypto API

Posted Oct 22, 2010 1:54 UTC (Fri) by neilbrown (subscriber, #359) [Link]

It is long past time that /proc/*/cmdline were not world-readable.

A netlink-based user-space crypto API

Posted Oct 22, 2010 9:09 UTC (Fri) by nix (subscriber, #2304) [Link]

Unfortunately there are a *lot* of scripts out there that depend on 'ps -o args' and similar commands working for users other than the current one. Really a lot. This would, of course, break them all.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds